このような不良セクタについて知らされていると考えてください。
[48792.329933] Add. Sense: Unrecovered read error - auto reallocate failed
[48792.329936] sd 0:0:0:0: [sda] CDB:
[48792.329938] Read(10): ...
[48792.329949] end_request: I/O error, dev sda, sector 1545882485
[48792.329968] md/raid1:md126: sda: unrecoverable I/O read error
for block 1544848128
[48792.330018] md: md126: recovery interrupted.
このセクターが含まれている可能性のあるファイルを見つけるにはどうすればよいですか?セクターをファイルにマップする方法は?または、ファイルシステムの空き領域にマップされているだけかどうかを確認するにはどうすればよいですか?
マッピングプロセスは、通常のストレージスタックを処理できる必要があります。
たとえば、上記の例では、スタックは次のようになります。
/dev/sda+sdb -> Linux MD RAID 1 -> LVM PV -> LVM VG -> LVM LV -> XFS
しかし、もちろん、次のように表示されることもあります。
/dev/sda+sdb -> Linux MD RAID 1 -> DM_CRYPT -> LVM PV -> LVM VG -> LVM LV -> XFS
従来の方法は、すべてのファイルを他の場所にコピーして、どのファイルが読み取りエラーをトリガーするかを確認することです。もちろん、エラーがRAID層の冗長性によって隠されている場合、これは質問にまったく答えません。
それとは別に、私は手動のアプローチしか知りません。これは面倒すぎて実際に実行することはできません。この魔法を実行するツールがある場合、まだ聞いたことがありません。より一般的なツール(blktrace
など)が役立つかどうかはわかりません。その点。
ファイルシステムの場合、filefrag
またはhdparm --fibmap
を使用して、すべてのファイルのブロック範囲を決定できます。一部のファイルシステムは、他の方向にルックアップを行うためのツールを提供します(例:debugfs icheck
)が、同じことを行うsyscallを知らないため、ブロック->ファイルルックアップ用の汎用インターフェイスがないようです。
LVMの場合、lvs -o +devices
を使用して、各LVが格納されている場所を確認できます。また、pvs -o +pe_start,pe_size
を知る必要があります。実際には、vgcfgbackup
の方が読みやすい場合があります。これにより、ファイルシステムアドレスを各PVのブロックアドレスに変換できるようになります。
LUKSの場合、オフセットはcryptsetup luksDump
で確認できます。
Mdadmの場合、オフセットはmdadm --examine
で確認できます。 RAIDレベルが1以外の場合は、計算も行う必要があります。具体的には、md
デバイスのどのアドレスがどのRAIDメンバーデバイスのどのブロックに変換されるかを理解するために、RAIDレイアウトを知る必要があります。 。
最後に、パーティション化せずにディスクを直接使用していない限り、パーティションオフセットを考慮する必要があります。