☰

背景

tag-icon • tag-icon linux mdadm software-raid
背景

今日私はraid6配列（ext4ファイルシステムを使用）を確認しましたが、2つのカーネルメッセージが表示されました。

mismatch sector in range 2842495632-2842495640
mismatch sector in range 2927793488-2927793496

これまでは、このセクターにどのファイルがあるかを見つけることができなかったため、Googleで有用な情報を検索することは不可能でした。

たぶんこれは私の要件をよりよく説明するかもしれません。仮想の有用性が与えられたら、電話をかけて同様の答えを受けたいとfind-file思います。find-file 2842495632/mnt/raid/this-file-has-a-mismatch

答え1

免責事項：
これはすべて間違っている可能性があります。私はここに非常に深く関与し、間違いが簡単ですが、あなたが正しいことを確認するのは難しいです。報告されたセクタはすべて512バイトであると仮定します。間違っている可能性があるオフセットもあります。
私の理解が十分に正確であることを願っていますが、時間が教えてくれます。エラーが見つかったら訂正してください！
すべてのコマンドを実行するには root 権限が必要です。常にバックアップしておくことをお勧めします。

背景

私はあなたと同じ問題で苦労しています。不良ディスクコントローラカードにより、RAID6のドライブの半分が消えました。悪い。ここで、一致しないMDセクタが48個あり、ここにどのファイルが保存されているかを調べたいと思います。私の設定はあなたの設定と似ていますが、LVMでも混在しています。

多くの人が実際にLVMを使用していて、設定に関する詳細情報をたくさん提供していないため、この回答は私の設定にのみ当てはまります。これも私がテストできる唯一のものです。
あなたの場合は、LVMの周りをスキップしてください。 md配列を分割した場合は、ファイルシステムのオフセットも見つける必要があります。いずれにせよ、少なくともいくつかのアイデアを提供する必要があります。

設定

ストレージ設定は次のとおりです。6
台のSATAドライブのMdroid RAID6（/ dev / md1）。このアレイは、LVM2ボリュームグループ「vg_arch」のPVとして使用されます。 VGには複数のLVがあり、そのうちの1つはExt4形式の「lv_arch2」です。

したがって、HDD→MD→LVM→Ext4があります。

質問

mdraid配列（）を調べた後、/usr/share/mdadm/checkarray -a /dev/md1次の行が見つかりました/var/log/syslog。

Jan  4 03:28:28 orion kernel: [36199.659889] md1: mismatch sector in range 2684449552-2684449560
Jan  4 03:28:28 orion kernel: [36199.659897] md1: mismatch sector in range 2684449560-2684449568
Jan  4 03:28:28 orion kernel: [36199.659901] md1: mismatch sector in range 2684449568-2684449576
Jan  4 03:28:28 orion kernel: [36199.659904] md1: mismatch sector in range 2684449576-2684449584
Jan  4 03:28:28 orion kernel: [36199.659921] md1: mismatch sector in range 2684449584-2684449592
Jan  4 03:28:28 orion kernel: [36199.659925] md1: mismatch sector in range 2684449592-2684449600

ここでの問題は、RAIDアレイの一部のブロックが破損してデータを信頼できないことです。これに対するさまざまな理由はほとんど無限ですが、セクタが不良なので、そこにファイルが保存されているのか、それならどのファイルなのかを調べる必要があります。
私の場合、配列は50/50に分割され、mdraidがどのデータを使用するのかわかりませんでした。

不良セクタの範囲は2684449552 – 2684449600、合計48個です。

データの破損を防ぐために、最初にRAIDリカバリを読み、リカバリを試みるときに上書きを使用することをお勧めします。すべてを破壊するのはとても簡単です。

少なくとも読み取り専用モードでアレイを組み立てて動作すると仮定する。テスト時にオーバーライドを使用して、誤って実際の配列に何も書きませんでした。このガイドでは読み取り専用アクセスのみが必要です。

部門狩り

まず、カーネルから取得したセクタ番号はmd配列のセクタです（少なくとも私の仮定はそうです）。これは、ストレージスタックの低レベル（パーティションオフセットなど）について考える必要がないため、作業が少し簡単になるためです。

私たちが従うべきパスは次のとおりです。HDD→MD→LVM→Ext4→File

左心室容積

MDレベルに達したので、LVMを見てください。

LVMスタックの一番下はPV（物理ボリューム）です。これは複数のエクステントに分割され、1つ以上のエクステントが論理ボリューム（LV）を形成します。物理ボリュームは基本デバイスにすぎないため、この場合は/dev/md1。

PVのデータはセクタ0から直接開始されませんが、オフセットがあります。最初のセクタはLVMメタデータに使用されます。まず、PVの開始範囲がどれだけ離れているかを把握する必要があります。

# pvs --noheadings -o pe_start --units s /dev/md1
2048S

データはＰＶのセクタ２０４８から始まる。問題のセクタは2684449552-2048 = 2684447504LVMのセクタで始まり終了します2684449600-2048 = 335555944。

次に、LVMの範囲がどれだけ大きいかを知る必要があります。

# pvdisplay --units s /dev/md1 | grep 'PE Size'
PE Size               8192 Se

各LVM範囲には8192個のセクタがあります。

これで問題が始まった程度を計算できます。2684447504/8192 = 327691,345703125 extents

そのセグメントが正確なPE境界にないため、これは小数です。残りはPEのセクタオフセットを提供します。 0,345703125*8192 = +2832 sectors

次のステップは、PE 327691を使用するLVを見つけることです。

# pvdisplay --maps /dev/md1 | grep -A1 'Physical extent'
  Physical extent 0 to 2621439:
    Logical volume  /dev/vg_arch/lv_arch2
--
  Physical extent 2621440 to 3801087:
    Logical volume  /dev/vg_arch/lv_test

/dev/vg_arch/lv_arch2PEがLVに属し、オフセットがないことがわかります。相殺された場合は、これを考慮する必要があります。

アウトライン4

これで、ファイルシステムレベルに進むのに十分な情報があります。まず、私たちが使用しているセクター/ブロックサイズを知る必要があります。

# fdisk -u -l /dev/md1
Disk /dev/md1: 14.52 TiB, 15959456743424 bytes, 31170813952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 1048576 bytes / 4194304 bytes

md配列は512バイトセクタを使用します。 （これが正しいかどうかはわかりません。デフォルトでは、カーネルがエラーを報告するときに同じセクタサイズを使用すると仮定しました。）

Ext4ブロックサイズを取得するには：

# tune2fs -l /dev/vg_arch/lv_arch2 | grep Block
Block count:              2684354560
Block size:               4096

ファイルシステムは4KiBブロックを使用します。これはブロックあたり8セクタに対応します。

mdadmセクタ番号は同じではないので、Ext4ブロック番号に変換する必要があります。これには、次の式を使用できます。

(mdadm sector number) / ((filesystem block size) / (mdadm sector size)) = Ext4 block number

この場合、以下があります。

2684447504 / (4096 / 512) = 335555938 (start)
2684447552 / (4096 / 512) = 335555944 (stop)

したがって、Ext4ファイルシステムで問題となるブロックの範囲は335555938〜335555944です。

書類確認

ブロック番号があれば、そこに保存されているファイルを参照できます。これはを使用して行うことができますdebugfs。

# debugfs
debugfs:

debugfs次に、コンソールでopenコマンドを使用してファイルシステムを開きます（まだインストールされていない必要があります）。

debugfs:  open /dev/vg_arch/lv_arch2

大容量のファイルシステムがある場合、この操作にはしばらく時間がかかることがあります。

これで、これらのブロックが使用されているかどうかテストを開始できます。運が良ければ、不良ブロックはどのファイルでも使用されません。それをテストするために使用してくださいtestb blocknumber。

debugfs:  testb 335555938
Block 335555938 not in use

すべての不良ブロックに対してこのコマンドを繰り返し、次のように使用されたすべての不良ブロックを記録します。

debugfs:  testb 335555944
Block 335555944 marked in use

すべてのブロックが使用されていない場合は完了です。おめでとうございます！それ以外の場合は、影響を受けたファイルを見つけ続ける必要があります。

次のステップは、ブロックを使用するinodeを見つけることです。

debugfs:  icheck 335555944
Block   Inode number
335555944   279577043

したがって、影響を受けたinode 279577043があります。ファイル名を探してみましょう。

debugfs:  ncheck 279577043
Inode   Pathname
279577043   /my_files/file.dat

最後に、破損したmdadmセクタの影響を受けるファイルが見つかりました。あまり難しくありません。 ;-)

終了するには、コマンドを実行してclose終了quitしますdebugfs。

源泉

この問題に関する情報を見つけるのは難しいですが、私が最も頻繁に使用しているサイトは次のとおりです。

関連情報