この情報源から、最終的にIceWhaleの根本原因が確認されました。ZimaOS 1.5.3へのアップグレード後、NVMe RAIDアレイ自体は正常に構成されてマウントされましたが、 zimaos-local-storage RAIDデータベースに fs_type = 'BTRFS' ストレージマネージャーが期待する小文字の値ではなく、大文字で保存されていました。
IceWhaleのDinaは、対象を絞ったSQLite更新を提供しました。元の投稿者はそれを実行し、その後RAIDが正常にマウントされたことを明確に確認しました。その後、ZimaOS 1.5.4では、大文字のBTRFSによるRAID自動マウント問題が正式な修正項目として記載されました。したがって、現在のユーザーはこのSQLを、特定のバグに対する過去の復旧手順として扱うべきであり、一般的なRAID修復コマンドとして使用すべきではありません。
RAIDアレイはストレージマネージャーによってアンマウントされる前は正常だった
ジャーナルには、カーネルがRAIDを自動検出し、systemdがマウントしたことが記録されていました /media/RAID-Storage-2、そして zimaos-local-storage 数秒後に強制的にアンマウントされたことが示されていました。
ソースのデータベースレコードにも、RAIDが status ok。これにより、メンバーの故障やBtrfsファイルシステムの破損の可能性は低くなりました。
手動のfstab設定は一時的な回避策としてのみ機能した
ユーザーはRAIDを手動でマウントし、 /etc/fstab エントリがありましたが、ZimaOSのストレージ管理はそれを正式な設定として扱いませんでした。再起動すると、local-storageサービスは内部データベースと状態を引き続き適用しました。
このため、アプライアンスが管理するストレージは通常、手動マウントとして別途管理するのではなく、ZimaOSのストレージレイヤーを通じて修復すべきです。
コミュニティはzimaos-local-storageが該当レイヤーであることを正しく特定した
IceWhaleが根本原因を公表する前に、gelbuildingは重要な一連の動作に気づきました。マウントには成功し、その後 zimaos-local-storage アンマウントします。彼は、RAIDメタデータを繰り返し変更するのではなく、IceWhaleにログを送るよう適切に助言しました。
より厳格な検証が原因だという彼の推測は最終診断ではありませんでした。その後の公式診断では、原因がより具体的に特定されました。
IceWhaleがfs_typeの大文字・小文字の誤りを発見
Dinaは、データベースの fs_type 値が大文字で保存されていたため、マウントに失敗していました。IceWhaleは次のコマンドを提供しました。
sudo sqlite3 /var/lib/casaos/db/local-storage.db "UPDATE raids SET fs_type = 'btrfs' WHERE fs_type = 'BTRFS';"その後、ユーザーは「これは実際に問題を解決しました」と返信しました。
BTRFS 小文字に btrfs.ZimaOS 1.5.4で同じ自動マウントのバグが正式に修正された
1.5.4のリリースノートには、RAIDデータベースのレコードに保存された値が原因で自動マウントに失敗する問題の修正が明記されています BTRFS 大文字で。
ZimaOS 1.5.4の公式RAIDマウント修正をご覧ください。
後の1.5.4ユーザーもRAIDがマウントされないと報告
別の参加者は、1.5.4システムでもマウント問題が発生したと述べました。Dinaは、それが依然として大文字のfs_typeバグだと決めつけず、新しいディスク診断情報と症状の説明を求めました。
それが正しい判断基準です。似た症状でも原因が異なる場合があります。
一致する証拠がない限り、現在のRAIDで古いSQLを実行しないでください
現在のZimaOSは1.7.1です。手を加える前に local-storage.db、次を確認してください。
- アレイが実際に組み立てられている。
- ジャーナルにlocal-storageサービスがアンマウントしていることが示されている。
- データベースに実際に過去の大文字の値が含まれている。
- 現在のバックアップと診断レポートがある。
これらの条件が一致しない場合、データベースを編集すると、別のストレージ問題からの復旧が難しくなる可能性があります。
ユーザーが適切なログを提供したことで公式修正が見つかった
IceWhaleは要求しました /ZimaOS-HD/.log/casaos/local-storage.log コミュニティがストレージマネージャー層を特定した後。そのログによって、チームは広範な仮説から正確な大文字・小文字のバグへと絞り込むことができました。
現在のマウント障害については、メタデータを変更する前に、RAIDの組み立て状態、ジャーナルの行、ZimaOSのストレージ状態、ローカルストレージの診断情報という同じ証拠パターンを保存してください。
手動でデータベースを編集する前に内部メタデータをバックアップする
元のSQLは、既知の1.5.3の不具合に対するIceWhale提供の1行修正でした。今後、スタッフの案内によるデータベース編集が必要になった場合は、まずデータベース／状態のバックアップを作成し、修正対象の正確な条件にのみ適用してください。
RAIDレコードに対する広範なSQL更新は、ストレージマネージャーの認識を実際のアレイから切り離し、復旧可能なマウントバグをメタデータ復旧の問題に変えてしまう可能性があります。
正常だがマウントされないRAIDに対して、再インストールは最初に行う対応ではない
アレイ自体は正常に組み立てられ、データも無事だったため、RAIDを再インストールまたは再作成するのは不必要に破壊的でした。正常なアレイが管理メタデータによって拒否されている場合は、アレイの構成に手を加える前に、管理レイヤーを修復するか、ベンダーのサポートを利用してください。
RAIDマウントに関するよくある質問
ソース側でRAID自体が破壊されていたのですか？
いいえ。アレイは、ZimaOSのストレージ管理がアンマウントする前に組み立てられ、マウントされていました。
確認された根本原因は何でしたか？
RAIDデータベースに保存されていた fs_type 大文字として BTRFS 小文字の代わりに btrfs.
IceWhaleはこれをリリースで修正しましたか？
はい。ZimaOS 1.5.4では、大文字のBTRFSによる自動マウントのバグが修正済みと明記されています。
