☰

不良セクタの影響を受けるファイルを見つける方法は？

tag-icon • tag-icon linux filesystems data-recovery disk
不良セクタの影響を受けるファイルを見つける方法は？

以下の不良セクタに関する情報を受け取ったとします。

[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

ベストアンサー1

伝統的なアプローチは、すべてのファイルを別の場所にコピーし、どのファイルが読み取りエラーを引き起こすかを確認することです。もちろん、RAIDレイヤーの重複によってエラーが隠れる場合、これは質問にはまったく答えません。

それ以外は手動の方法だけ知っています。これは実際に実行するのが面倒で、これらの魔法を実行できるツールがあれば聞いたことがなく、blktraceView（Viewなど）のより一般的なツールが役に立つかどうかはわかりません。

ファイルシステムの場合またはfilefragを使用して、hdparm --fibmapすべてのファイルのブロック範囲を決定できます。一部のファイルシステムは異なる方向にナビゲートする機能を提供しますが（たとえばdebugfs icheck）、同じ操作を実行するシステムコールを認識しないため、ブロック - >ファイルナビゲーションに共通のインターフェイスがないようです。

LVMの場合、各LVが保存されている場所を確認するには、物理​​範囲オフセット/サイズlvs -o +devicesも知っている必要があります。pvs -o +pe_start,vg_extent_size実際に機能することもできますvgcfgbackup。これにより、ファイルシステムアドレスを各PV内のブロックアドレスに変換できます。

LUKSの場合、オフセットを見ることができますcryptsetup luksDump。

mdadmの場合、オフセットを見ることができますmdadm --examine。 RAIDレベルが1でない場合は、計算も実行する必要があります。特にRAIDレイアウトを理解して、デバイスのどのアドレスがどのmdRAIDメンバーデバイスのどのブロックに変換されるかを知る必要があります。

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

おすすめ記事