TL; DRの要約：mdセクター番号を/dev/mdXデバイス内のオフセットに変換し、それをで調査する方法xfs_db。セクター番号はからのものsh->sectorですlinux/drivers/md/raid5.c:handle_parity_checks5()。
MDの内部がわからないので、printk追加したログからの出力をどうするか正確にわかりません。
コンポーネントデバイス（ddまたはhexエディター/ビューアー）へのオフセットも興味深いでしょう。
Linux-raidメーリングリストでこれを尋ねるべきだと思います。サブスクライバーのみですか、またはサブスクライブせずに投稿できますか？
私のデスクトップでは、4つのディスクのMD RAID5の上に直接xfsがあります（LVMなし）。最近のスクラブでゼロ以外が検出されましたmismatch_cnt（mdは一度に4kiBページで動作するため、実際には8）。
これはRAID5であり、通常の動作中に！= 0が発生する可能性があるmismatch_cnt RAID1 / RAID10 ではありません。（このWikiページの下部にある他のリンクは、一部の人々にとって役立つかもしれません。）
私は盲目的にできましたrepairが、どのファイルを再構築するかを選択する機会を失う以外に、破損の可能性をチェックするファイルがわかりません。 同様の質問に対するFrostschutzの回答は、ファイルシステムの違いを追跡するために私が見つけた唯一の提案です。面倒で遅いので、最初にいくつかのファイルに絞り込むために、より良いものを使用したいと思います。
ロギングを追加するカーネルパッチ
奇妙なことに、mdのチェック機能は、エラーが見つかった場所を報告しません。 私は追加printkログインするには、MD / raid5.cにsh->sectorにif増加することを支店mddev->resync_mismatches内handle_parity_checks5()（小さなパッチgithubの上で公開され、もともとkernel.orgから4.5-RC4に基づいて、。）これは一般的な使用のためにOKであるために、それはおそらくする必要があります不一致が多い修理でログが殺到しないようにします（たぶん、新しい値がresync_mismatches1000未満の場合にのみログを記録しますか？）。また、ログのみでログはないかもしれcheckませんrepair。
同じ関数がそのセクター番号をのエラー処理の場合にswitch出力するので、（MDの内部を知らなくても）何か有用なものをログに記録していると確信しています。
変更したカーネルをコンパイルして起動し、チェックを再実行しました。
[ 399.957203] md: data-check of RAID array md125
...
[ 399.957215] md: using 128k window, over a total of 2441757696k.
...
[21369.258985] md/raid:md125: check found mismatch at sector 4294708224 <-- custom log message
[25667.351869] md: md125: data-check done.
現在、そのセクター番号をどうするか正確にはわかりません。あるsh->sector * 512線形アドレス内は/dev/md/t-r5（別名/dev/md125）？各コンポーネントデバイス内のセクター番号ですか（3つのデータと1つのパリティセクターを指します）？RAID5のパリティ不一致は、mdデバイスのN-1セクターが危険にさらされており、ストライプユニットによって互いにオフセットされているため、後者を推測しています。セクター0はコンポーネントデバイスの最初の始まりですか、それともスーパーブロックまたは何かの後のセクターですか？handle_parity_checks5()計算/記録する必要があるという情報がもっとありましたか？
不一致のブロックのみを取得したい場合、これは正しいですか？
dd if=/dev/sda6 of=mmblock.0 bs=512 count=8 skip=4294708224
dd if=/dev/sdb6 of=mmblock.1 bs=512 count=8 skip=4294708224
dd if=/dev/sda6 of=mmblock.2 bs=512 count=8 skip=4294708224
dd if=/dev/sdd of=mmblock.3 bs=512 count=8 skip=4294708224 ## not a typo: my 4th component is a smaller full-disk
# i.e.
sec_block() { for dev in {a,b,c}6 d; do dd if=/dev/sd"$dev" of="sec$1.$dev" skip="$1" bs=512 count=8;done; }; sec_block 123456
4つのraidコンポーネントすべてから4kのゼロを取得しているので、私はそうではないと思います0^0 == 0。それで、正しいパリティになるはずですよね？
mdでセクターアドレスを使用することに言及した他の場所はsync_min、sync_max（sysfs内の）とです。 linux-raidリストのNeil Brownが、セクター番号がのドライブの故障についての質問に答えhdrecover、Neilはフルディスクセクター番号をMDセクター番号として使用しました。そうじゃないですか？mdセクター番号は、パーティションが含まれている完全なデバイスではなく、コンポーネントデバイス（その場合はパーティション）に関連していませんか？
XFSファイル名への線形セクター：
mdセクター番号がRAIDデバイスではなくコンポーネントのものであることに気づく前に、読み取り専用でそれを使用してみましたxfs_db：
XFSが特定のブロックをどのように使用しているかを見つける方法に関するDave Chinnerの非常に短い提案は、私にはまったく機能しないようでした。（不一致のセクターでなくても、デバイスの末尾を超えてはならないため、一部のセクターでは何らかの結果が予想されます）
# xfs_db -r /dev/md/t-r5
xfs_db> convert daddr 4294708224 fsblock
0x29ad5e00 (699227648)
xfs_db> blockget -nv -b 699227648
xfs_db> blockuse -n # with or without -c 8
must run blockget first
え？ここで何が悪いのですか？これは別の質問になると思います。質問したり、この部分への回答を他の場所で見つけたりした場合は、これをリンクに置き換えます。
私のRAID5は基本的にアイドル状態であり、書き込みアクティビティnoatimeはなく、読み取りも最小限です（したがって、読み取りでは書き込みは行われません）。
私のセットアップに関する余分なもの、ここでは何も重要ではありません
私のファイルの多くはビデオまたはその他の圧縮データであり、データが正しいかどうか（ファイル形式の内部チェックサム、またはエラーなしでデコードされるかどうか）を確認する効果的な方法を提供します。チェックするファイルが分かれば、この読み取り専用ループバックメソッドは実行可能になります。しかし、カーネルがチェック中に必要な情報を持ち、簡単にログに記録できる場合、最初に不一致を見つけるためにファイルシステム内のすべてのファイルの4方向差分を実行したくありませんでした。
私の/proc/mdstatバルクデータ配列：
md125 : active raid5 sdd[3] sda6[0] sdb6[1] sdc6[4]
7325273088 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 0/19 pages [0KB], 65536KB chunk
これは、3台の東芝3TBドライブのパーティションと、パーティション化されていないWD25EZRSグリーン電源（低速）ドライブにあり、別の東芝と交換しています。（mdadm --replace冗長性にギャップのないオンラインでの使用に使用しています。1つのコピーの後に、問題を検出するために前後にRAIDの状態をチェックする必要があることに気付きました。そのとき、不一致を検出しました。長い間使用されている可能性があります。 、ほぼ1年前にいくつかのクラッシュが発生したため、古いログがなく、mdadmはデフォルトでこれに関するメールを送信しないようです（Ubuntu 15.10）。
私の他のファイルシステムは、3つの大きなHD（および/ var / tmpのRAID0）の以前のパーティションから作成されたRAID10f2デバイス上にあります。RAID5は大容量ストレージ専用であり、/homeまたはではありません/。
私のドライブはすべて正常です。SMARTエラーカウントは0で、すべてのドライブのすべての不良ブロックカウンターで、短い+長いSMARTセルフテストに合格しています。
回答がないこの質問のほぼ重複：
.damagedます。
mdadm -E /dev/xxx。