web-dev-qa-db-ja.com

どのファイルが不良セクタの影響を受けているかを見つける方法は?

このような不良セクタについて知らされていると考えてください。

[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
7
maxschlepzig

従来の方法は、すべてのファイルを他の場所にコピーして、どのファイルが読み取りエラーをトリガーするかを確認することです。もちろん、エラーが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レイアウトを知る必要があります。 。

最後に、パーティション化せずにディスクを直接使用していない限り、パーティションオフセットを考慮する必要があります。

5
frostschutz