TL; DR摘要：将md扇区号转换为/dev/mdX设备内的偏移量，以及如何使用进行调查xfs_db。扇区号来自sh->sector中linux/drivers/md/raid5.c:handle_parity_checks5()。
我不知道MD的内部原理，所以我不知道该如何处理printk我添加的日志记录的输出。
偏移到组件设备中（对于dd十六进制编辑器或查看器）也将很有趣。
我想我应该在Linux突袭邮件列表中问这个问题。它是仅订阅者，还是可以不订阅而发布？
我将xfs直接放在桌面上的4个磁盘的MD RAID5上（没有LVM）。最近的mismatch_cnt清理发现非零值（实际上是8，因为md一次在4kiB页上运行）。
这是RAID5，而不是RAID1 / RAID10 ，mismatch_cnt在正常操作期间，其中！= 0可能会发生。（此Wiki页面底部的其他链接可能对某些人有用。）
我可以盲目地做repair，但是那时我不知道该检查哪个文件可能的损坏，除了失去选择哪种重建方法的机会。 Frostschutz对类似问题的答案是我发现的唯一回溯到文件系统差异的建议。它既麻烦又缓慢，我宁愿使用更好的方法来首先将其缩小到几个文件。
内核补丁添加日志
奇怪的是，md的检查功能不会报告发现错误的位置。 我加入了printk在MD / raid5.c记录sh->sector在if该增量分支mddev->resync_mismatches中handle_parity_checks5()（小片在github上发布，最初基于4.5 RC4从kernel.org。）对于这个是确定用于一般用途，它可能会需要避免充斥大量不匹配的维修日志（也许仅在新值resync_mismatches<1000 时才记录日志）。也可能只登录check而不是repair。
我敢肯定，我正在记录一些有用的信息（即使我不知道MD内部信息！），因为在处理错误的情况下，switch相同的函数会打印该扇区号。
我编译了修改后的内核并启动了它，然后重新运行检查：
[ 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.
现在我不知道该如何处理该扇区号。（aka ）sh->sector * 512里面是线性地址吗？它是每个组件设备中的一个扇区号（因此它指的是三个数据和一个奇偶校验扇区）吗？我猜是后者，因为RAID5中的奇偶校验不匹配意味着md设备的N-1个扇区处于危险之中，彼此之间被条带单元偏移。扇区0是组件设备的最开始，还是在超级块之后的扇区或其他内容？我是否应该计算/记录更多信息？/dev/md/t-r5/dev/md125handle_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
我猜不是，因为我从所有四个RAID组件中得到4k的零，并且0^0 == 0，那应该是正确的奇偶校验，对吗？
我看到的另一个在md中使用扇区地址的地方是for sync_min和sync_max（在sysfs中）。 linux-raid列表上的Neil Brown回答了有关扇区号为的驱动器发生故障的问题hdrecover，其中Neil使用全盘扇区号作为MD扇区号。那不对吗？md扇区号不是相对于组件设备（在这种情况下是分区），而不是相对于该分区所属的完整设备吗？
线性扇区到XFS文件名：
在意识到md扇区号可能是用于组件而不是RAID设备之前，我尝试以只读方式使用它xfs_db：
Dave Chinner关于如何查找XFS如何使用给定块的非常简短的建议对我似乎根本不起作用。（对于某些扇区，我可能会期望得到某种结果，因为即使它不是不匹配的扇区，该数字也不应超出设备的末尾）
# 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
它位于三个Toshiba 3TB驱动器的分区上，以及一个非分区的WD25EZRS绿色电源（慢速）驱动器上，我将用另一个Toshiba替换它。（使用mdadm --replace联机进行此操作时，没有冗余上的空隙。我意识到在复制一份副本之前和之后都应该检查RAID运行状况，以发现问题。那是我检测到不匹配的地方。很可能已经存在很长时间了，因为大约一年前发生了一些崩溃，但是我没有旧的日志，因此mdadm似乎默认不会发送与此相关的邮件（Ubuntu 15.10）。
我的其他文件系统在RAID10f2设备上，该设备由三个较大的HD上的较早分区（对于/ var / tmp为RAID0）组成。RAID5仅用于大容量存储，不能用于/home或/。
我的驱动器一切正常：SMART错误计数为0，所有驱动器上的所有坏块计数器均已通过，并且通过了长短SMART自检。
这个问题几乎没有答案：
.damaged或东西，而不是只知道有可能是一个坏文件的某处。
mdadm -E /dev/xxx。