SLES Btrfsが読み取り専用になった場合:再マウントする前に診断を行う
Btrfsが意図的に読み取り専用になっているのか、容量不足なのか、エラー発生後のデータ保護のために動作しているのかを特定し、その原因に合った復旧方法を選択してください。
SUSE Linux EnterpriseのBtrfsファイルシステムで「読み取り専用ファイルシステム」と表示される場合は、まず、意図的に読み取り専用でマウントされたのか、エラー後に読み取り専用に切り替わったのかを確認してください。再マウントを試みる前に、マウントオプション、空き容量、カーネルログを確認してください。検証済みの起動可能なシステムスナップショットを取得するには、Snapperロールバックを使用してください。BtrfsでI/Oエラーまたはメタデータエラーがログに記録された場合は、データを保護し、ストレージパスを診断してから、ファイルシステムに再度書き込んでください。

/data影響を受けるマウントポイント、または/ルートに置き換えてください。
findmnt -T /data -o SOURCE,FSTYPE,OPTIONS
sudo btrfs filesystem show /data
最初のコマンドで、オプションの中にroまたはを探してくださいrw。読み取り専用の Snapper スナップショットは、書き込みを拒否することが想定されています。 で構成されたマウントroも/etc/fstab意図的な場合があります。Btrfs は、深刻なトランザクション、メタデータ、またはデバイスのエラーが発生すると、読み取り専用に切り替わることもあります。その場合、 を繰り返し実行してもmount -o remount,rw原因は修復されず、すぐに失敗する可能性があります。
ファイルシステムが意図的に読み取り専用でマウントされ、デバイスが正常で、カーネルログにBtrfsまたはI/Oエラーがない場合、通常のデータマウントを読み書き可能で再マウントできます。
sudo mount -o remount,rw /data
findmnt -T /data -o TARGET,OPTIONS
ブート時に読み取り専用スナップショットが作成された状態、またはエラーによって強制的に読み取り専用ファイルシステムが作成された状態の復旧コマンドとして、このコマンドを使用しないでください。再マウントが成功したとしても、書き込み可能性は確認されるものの、ファイルシステムの整合性は保証されません。

Btrfsでは、基本的なディスクビューでは驚くほど空き容量が少ないように見えても、データとメタデータの割り当てが別々に追跡されるため、割り当て可能な領域が不足することがあります。通常の空き容量とBtrfsの使用状況の両方を確認してください。
df -hT /data
sudo btrfs filesystem usage -T /data
システムがNo space left on deviceデバイス障害や構造エラーを報告し、カーネルログにもエラーが表示されない場合は、何かを削除する前にSnapperの使用状況を確認してください。
sudo snapper list
保持ポリシーで削除が許可されているスナップショットのみを、sudo snapper delete SNAPSHOT_ID選択したIDごとに削除してください。ロールバックオプションが必要な場合は、更新前の正常なスナップショットを保持してください。スナップショットを削除すると空き容量は回復しますが、回復ポイントは削除されます。クリーンアップ後すぐに空き容量が回復しない場合があり、スナップショットではI/Oエラーは修正されません。読み取り専用ファイルシステムを強制的に書き込み可能にするためにバランスを実行しないでください。バランスはデータを移動させるものであり、正常な書き込み可能なファイルシステムで診断された割り当ての問題を対象としています。

ファイルシステムが読み取り専用になったという最終メッセージだけでなく、最初のBtrfs、ブロックデバイス、コントローラー、またはトランスポートのエラーを探してください。
sudo journalctl -k -b --no-pager | grep -Ei 'btrfs|I/O error|nvme|ata|scsi'
読み取り失敗、チェックサムの不一致、デバイスの欠落、またはI/Oエラーに関するメッセージは、単純なマウントオプション以外の原因を示していますro。報告されたディスク、コントローラ、RAID/HBA、SANまたは仮想ディスクレイヤー、およびベンダーの健全性情報を確認してください。まず、不安定なハードウェアまたは接続を修正してください。データが重要な場合は、書き込みを最小限に抑え、ファイルシステムの修復を試みる前に、管理者と協力してバックアップまたはブロックレベルのイメージを作成してください。
| 見つかったもの | 次のアクション | トレードオフ |
|---|---|---|
ro設定されているか、マウントが意図的に読み取り専用になっています。関連するカーネルエラーはありません。 | 意図しないマウント構成になっている場合は修正するか、デバイスが正常であることを確認した後、通常の書き込み可能なサブボリュームを再マウントしてください。 | 高速ではあるが、再マウントではエラーによって強制された読み取り専用状態を解除したり、読み取り専用のスナップショットを書き込み可能にしたりすることはできない。 |
| ブート可能なルートスナップショットは機能し、問題はシステム変更後に発生した。 | スナップショットを起動してテストし、その後、sudo snapper rollbackデフォルトのエントリを実行して再起動します。 | ルートサブボリュームをスナップショットの状態に復元します。除外されたサブボリュームまたは別のサブボリューム内のデータはロールバックされません。SLES 15 SP7 は、デフォルトのルートサブボリュームレイアウトと単一デバイスのルートファイルシステムでのみ、このロールバックをサポートします。 |
| カーネルログにストレージI/OエラーまたはBtrfs構造エラーが含まれています | ストレージを安定させ、データを保護する。レスキュー環境を使用し、ファイルシステム固有の復旧のためにエスカレーションを行う。 | 処理速度は遅くなるが、書き込み可能な再マウントによって未解決のハードウェア問題を隠蔽することを回避できる。 |
| 容量不足のみが報告され、ストレージエラーは発生していません。 | Snapperの保持期間と許可されているスナップショットまたはデータの空き容量を確認し、その後Btrfsの使用状況を再度確認してください。 | 選択した復元ポイントまたはファイルを犠牲にして、容量を解放します。 |

SLES では、起動可能なスナップショットはデフォルトの Snapper ルート構成を使用します。ルートは 1 つのデバイス上の Btrfs である必要があり、ブート ローダーがそれをサポートしている必要があり、ルート サブボリュームのみがロールバックされます。コミットする前に候補を確認してください。不適切な場合は、現在のシステムまたはレスキュー環境に再起動してください。SLES 15 SP7 Snapper ロールバック手順を参照してください。
ファイルシステムがマウントできない場合、またはカーネルメッセージに構造的な損傷が示唆される場合は、SLESレスキューシステムまたはその他の適切なリカバリ環境を起動し、正しいデバイスを特定して、デフォルトの読み取り専用チェックを実行する前に、そのデバイスがアンマウントされていることを確認してください。
sudo btrfs check /dev/DEVICE
マウントポイントのプレースホルダーではなく、実際の Btrfs ブロックデバイスを使用してください。チェックには時間とメモリが必要となり、構造的な結果が報告されますが、修復を保証するものではありません。--repairルーチンの次のステップとして追加しないでください。Btrfs のドキュメントには、修復によって状況が悪化する可能性があるため、データリスクを受け入れた上で専門家の指導の下でのみ使用すべきであると警告されています。チェックでエラーが報告された場合、またはデバイスに I/O 障害が発生した場合は、SUSE サポートまたは Btrfs の専門家にご相談ください。
ストレージが安定し、ファイルシステムが読み書き可能でマウントされたら、sudo btrfs scrub start -B /dataチェックサムを検証できます。スクラブは構造チェッカーではありません。既知の正常な冗長コピーからの損傷のみを修復できます。単一コピー構成では、エラーは検出できますが、失われたデータを再構築することはできません。Btrfsスクラブのドキュメントを参照してください。また、SUSE の SLES 15 SP7 ファイルシステムガイド、SUSE の Btrfs リカバリ記事、およびBtrfs チェックマニュアルも参照してください。
選択した復元手順の後、マウントポイントに意図したオプションが設定されており、安全な書き込みを実行できることを確認してください。
findmnt -T /data -o TARGET,SOURCE,FSTYPE,OPTIONS
sudo touch /data/.rw-check && sudo rm /data/.rw-check
ルートスナップショットのロールバックを行うには、まずシステムを再起動し、デフォルトシステムが正常に起動することを確認してください。次に、新しいカーネルログを確認し、Btrfsまたはデバイスのエラーが繰り返し発生していないか確認してください。読み書きフラグが表示されているだけでは、問題がないとは限りません。エラーが繰り返し発生する場合は、書き込みを停止し、ストレージ診断に戻ってください。
Btrfsが意図的に読み取り専用になっているのか、容量不足なのか、エラー発生後のデータ保護のために動作しているのかを特定し、その原因に合った復旧方法を選択してください。
ミラーリングされたチャネルを準備し、アクティベーションキーを作成し、マネージャーのチェックインに必要な接続を維持しながら、インターネットに直接アクセスできないSLES 15クライアントをブートストラップします。
YaSTのSSH経由のXIO起動エラーを修正し、X11転送とxauthを検証し、リモートウィンドウが不要な場合はncursesインターフェースに切り替えます。
アップデート前のBtrfsスナップショットを見つけて、読み取り専用でテストし、どのデータがルートロールバックの対象外になるかを理解した上で、Snapperを使用して永続的なリカバリを実行します。
SLESシステムのログを、認証済みTLS経由でリモートのrsyslogコレクターに送信します。この際、証明書のチェック、障害発生時のバッファリング、および配信テストが行われます。
RAM、スワップ、カーネル、およびZypperのログを使用して、実際のメモリ負荷を特定し、パッケージの状態を保護し、より安全なSLESアップグレードの再試行を選択します。
DebianのSSH経由の自動セキュリティアップデートを有効にし、デフォルトのパッケージソースを維持し、systemdとAPTのログを通じてスケジュールされた実行を確認します。
メール配信オプションを比較し、Ubuntu上でsmartdを設定し、ディスクの状態に関する警告が受信トレイに届くことを確認します。
Debian 12 で DNS ルックアップを復元するには、systemd-resolved をチェックし、必要に応じて resolv.conf を修復し、アップストリームの DNS およびアプリケーション解決を検証します。
Ubuntuでモニターまたはテレビを音声出力として認識させ、サウンド設定でそれを選択し、HDMIが表示されない場合は接続またはPipeWireデバイスリストを確認してください。