Block Storage for Classic のマウントがファイル・システム検査エラーで失敗するのはなぜですか?

ストレージボリュームのファイルシステムチェックに関する問題をトラブルシューティングします。

クラシック・インフラストラクチャー

を使用しているポッドのポッドログを表示 Block Storage for Classic すると、次の例のようなエラーが表示されます。

UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.(i.e., without -a or -p
options)

ディスクが破損している。 ディスク破損は、永続ボリューム（PV）がアクティブな読み書きモードにある状態で、関連するポッドが強制削除された場合、またはポッドが適切にエジェクションされる前にノードが再起動/再読み込みされた場合、もしくはボリュームがまだアタッチされた状態の時に発生します。 これらのシナリオでは、アンマウント処理が正しく完了せず、ボリュームが不整合な状態のまま残ります。 これは通常、ドレーン直後にノードの再読み込みや更新を実行するワークフローで発生します。この際、すべてのポッドが移行済みであり、ボリュームが切り離されていることを確認していません。

以下のコマンドを実行して、ポッドがマウントしている PV にパッチを適用します。

1. 障害が発生しているポッドの詳細を取得し、マウントされている PV と PVC をメモします。

   kubectl get pods
   

2. PVにパッチを適用して、 "ibm.io/autofix-fsckErr":"true" というアノテーションを追加してください。

   kubectl patch pv PVNAME -p '{"metadata": {"annotations":{"ibm.io/autofix-
   fsckErr":"true"}}}'
   

3. アプリ・ポッドを削除して再作成し、PV のマウントを再試行します。 ポッドを削除して再作成した後、 Kubernetes はマウント操作を再試行し、 Block Storage for Classic ドライバー・ポッドは "ibm.io/autofix-fsckErr":"true" アノテーションに基づいて問題の自動修正を試行します。

4. ポッドが正常にデプロイされて実行されたら、以下のコマンドを実行して PV を編集します。

   kubectl edit pv PVNAME
   

5. PV から "ibm.io/autofix-fsckErr: true" アノテーションを削除して保存します。

6. 問題が解決しない場合は、サポートにお問い合わせください。 サポート Case を開きます。 ケースの詳細には、関連するログ・ファイル、エラー・メッセージ、またはコマンド出力を必ず含めてください。