ログを再生するためにxfsボリュームをマウントできません。それで？
XFSでフォーマットされ、NFSを介して共有される42TB LUNは、顧客から「利用不可」と報告されました。結局、私はファイルサーバーを再起動することを余儀なくされました。 XFS LUNは修復されるまでマウントされません。修復するには、ログが再生され、コミットされていない変更がコミットされるようにマウントする必要があります。過去に、ログをダンプして修復を実行すると、LUN内のファイルとフォルダーの一部のファイル名が失われることを学びました。 42 TBそして潜在的に数十万のファイル。ファイル名の損失はデータの損失に相当します。
バックアップがあります。復元するには、リソースを収集する必要があります。そのLUNには約30TBのデータがあり、復元して元の場所にコピーして戻す必要があると思います。したがって、30 TBの空き領域が必要ですが、すぐには利用できません。
それらのログを再生して変更をコミットするためにXFSを強制的にマウントする別の方法はありますか？
これは、LUNの「フリーズ」が発生し、ログでxfsが破損していると報告され、サーバーを再起動してオンラインに戻すことを余儀なくされたのは3回目です。 XFSは確かな評判を持っているようです。それはかなり長い間存在しています。また、ファイルサーバーのOS（RHEL7）のデフォルトです。これらのLUNを強制終了する、構成にひどいエラーが発生しましたか？
SANは、ファイルサーバー上にLUN、マウントされたnodev、nosuid、nofailを提示します。同期として共有をマウントするワークステーションへのファイルサーバー共有。この組み合わせでファイルサーバーをハングさせるものはありますか？
ランチパッドのバグの更新をチェックするときにこの質問に出くわしました ＃168141 および ＃1686687 あなたが説明しているのと同様の症状で影響を受けました（XFSでもですがより大きなLUNで、ubuntu 16.04サーバーを実行している場合）。
ストレージシステム（大量のログを提供する）を非常に詳細にチェックしてきましたが（製造元にサポートを要求）、エラーや構成の誤りは見つかりませんでした。
これに何度か遭遇したことで、この動作の発生を、他の要因も調べることができるシステムに積極的に取り組んでいない可能性がある特定の時間にまで突き止めることができました。 cronでスケジュールされたfstrimの実行（ubtuntu 16.04サーバーのデフォルトです！）が週に1回開始されたことが、特に100TBを超えるサイズのLUNをfstrimするのに時間がかかるため、ファイルシステムの破損を引き起こしているように見えるという証拠がついに見つかりました。 。
ランチパッドに投稿されたバグがこの問題を説明している可能性が高いと思いますが、私にはこの問題のハッシュがアップストリームされていますが、これまでのところ実際には修正されていません。したがって、今のところ、それぞれのエントリフォームcron.weeklyを削除して、fstrimが実行されていないことを確認します。また、更新を実行した後にcronジョブが再度追加されているかどうかも確認します。これは、別の方法で解決したいものです。