コミュニティによるZimaOSの検証で、簡潔な回答が変わった
最初の回答では、ZimaOSは従来のパッケージマネージャーを持たない、最小構成のアプライアンス型システムとして扱われていました。apt installが使える、あるいはベースOSを恒久的に編集できると決めつけないよう勧められていました。よりクリーンな分離境界として、DockerやDebianまたはUbuntuの仮想マシンが提案されました。
その後の実機検証で、重要な訂正が加わりました。ある参加者はZimaCube上に/usr/bin/mergerfsとmergerfs-fusermountがすでに存在することを確認しましたが、SnapRAIDのバイナリは見つかりませんでした。別の参加者は、起動時の競合を調査する中で、同梱されているmergerfsが古いバージョンであることを特定しました。結論は「ネイティブインストールは不可能」ではなく、「ホストへの手動変更はサポート対象外で、バージョンの影響を受ける」というものでした。
手動で配置したバイナリは動作したが、アップデートのリスクがあった
あるユーザーはWSL2で実行ファイルをビルドしてZimaOSにコピーし、データディスク2台とパリティディスク1台による構成が動作したと報告しました。mergerfsのメンテナーは、静的ビルドによって手動配置が簡単になる場合がある一方、コンテナーの動作は、必要なFUSEマウントを公開できるだけ十分なrootful構成かどうかに左右されると指摘しました。
コミュニティからは、イミュータブル型のシステムにバイナリをコピーすると、保守作業が発生するという警告が繰り返し寄せられました。OTAアップデートによって手動変更が置き換えられたり、競合したりする可能性があり、ユーザーの検証中にはAIが生成したLinux向け手順にも誤りが含まれていました。
コミュニティがsystemd-sysextレイヤーを構築
その後、あるコントリビューターが、ZimaOS向けのmergerfsおよびSnapRAID用コミュニティ製systemd-sysextプロジェクトを公開しました。その目的は、読み取り専用のベースシステムを直接変更するのではなく、別個の拡張レイヤーとしてmergerfsとSnapRAIDを追加することでした。
管理されたZimaCube Proでのテストでは、このレイヤーが読み込まれ、mergerfs 2.42.0とSnapRAID 14.5が利用可能になり、一時的なmergerfsプールをマウントできることが確認されました。テスターはプールのパスからファイルを作成し、アンマウントを正常に行う前に、そのファイルが基盤となるブランチ上に現れることを確認しました。
このテストには、SnapRAIDの完全なパリティ作成および復旧検証は含まれていませんでした。また、テスターは設定を行う前に、デフォルトのタイマーとサービスを無効化しました。これにより、実ディスクに対して誤って処理が実行されるのを防ぎました。
2つの起動時競合が発見され、修正された
再起動後、あるユーザーはプールが失敗することがある一方、後から手動で起動すると成功することに気づきました。拡張機能の作者は、別々の2つの競合を特定しました。1つ目は、当初のガードがベースOSに付属する古いmergerfsバイナリを検出し、拡張機能の新しいバイナリが統合される前にプールを起動していたことです。修正版のガードでは、拡張機能によってのみ提供されるSnapRAIDの有無を確認するようになりました。
2つ目は、物理ブランチディスクがマウントされる前にmergerfsが成功を返す可能性があり、その結果、後から到着するストレージを隠す空のプールが生成されることでした。単純なRestart=on-failureのループでは、成功扱いになるものの空である状態を検出できません。そこでプロジェクトには、各ブランチのマウントを待機し、ブランチが欠落している状態ではプールの構築を拒否する明示的なチェックが追加されました。
作者は、これらの変更後にZimaOS 1.6.1でコールドブートからの再起動検証を行ったと報告しました。また、4台のディスクを搭載したTerraMasterエンクロージャーを使用するユーザーからは、ディスクのマウントに1分近くかかったものの、最終的にプールが表示されたという報告もありました。
SnapRAIDの安全性には、依然として運用担当者の確認が必要
この拡張機能には、予想外に大量の削除が発生した場合に同期を停止するための削除数しきい値が含まれていました。後から、数千個のファイルを意図的に削除した場合に、そのしきい値をどう上書きするのかを尋ねるユーザーが現れました。この運用上の疑問は、スレッド内では解決されませんでした。
このプロジェクトを評価する場合は、自動ジョブを有効にする前に、ブランチのパス、パリティのパス、タイマー、削除数のしきい値、アプリケーションデータの保存場所を確認する必要があります。バイナリが存在することやmergerfsのマウントに成功したことだけでは、本番データセットでパリティ復旧がテスト済みであるとは言えません。
サポート範囲
これはコミュニティが構築した高度な統合機能であり、IceWhaleがサポートするZimaOSのストレージ機能ではありません。Docker、完全なLinux仮想マシン、静的バイナリ、sysextには、それぞれ異なる権限と永続性の特性があります。このスレッドで最も有力な成果は検証済みの拡張方式ですが、実データを導入する前に、使い捨て可能なストレージで評価すべきです。
FAQ
mergerfsはZimaOSにすでに含まれていますか？
ある参加者は、自分のZimaCube上にmergerfsのバイナリがあることを確認しました。その後、このベースシステムのコピーは古いバージョンであることが判明したため、存在しているからといって、最新の構成との互換性が保証されるわけではありません。
SnapRAIDの復旧は完全にテストされましたか？
いいえ。管理されたテストでは、インストールと一時的なmergerfsプールを検証しましたが、SnapRAIDの完全なパリティ作成および復元テストは明確に実施されませんでした。
失敗したサービスを待つだけでは不十分だったのはなぜですか？
一方の競合では、終了コードが成功である空のプールが生成される可能性がありました。それは失敗として扱われないため、再起動オン失敗のルールだけでは見逃す可能性がありました。
