今天我检查我的 raid6 阵列（使用 ext4 文件系统）并弹出两条内核消息：
mismatch sector in range 2842495632-2842495640
mismatch sector in range 2927793488-2927793496
截至目前，我不可能通过谷歌搜索任何有用的信息，因为我无法找出哪些（如果有的话）文件驻留在这些扇区中。
也许这更好地解释了我的问题：给定一个假设的实用程序find-file，我想调用find-file 2842495632并得到类似的答案/mnt/raid/this-file-has-a-mismatch。
免责声明：
这可能都是错误的，我在这里处于深水状态，很容易犯错误，但很难验证你是否正确。我假设报告的扇区都是 512 字节。还有一些偏移量可能是错误的。
我希望我的理解足够正确，但时间会证明一切。如果您发现错误，请纠正我！
所有命令都需要 root 权限才能运行。备份总是好的。
背景
我正在努力解决与您相同的问题。由于磁盘控制器卡损坏，RAID6 中的一半驱动器消失了。不好。我现在有 48 个不匹配的 MD 扇区，想知道那里可能存储了哪些文件。我的设置与您的类似，但我还混合了 LVM。
这个答案是针对我的设置的，因为我认为许多人实际上也使用 LVM，而您没有提供那么多设置细节。这也是我唯一可以测试的。
在您的情况下，只需跳过 LVM 周围的部分。如果您对 md 数组进行了分区，您还必须找到文件系统的偏移量。无论哪种情况，它至少应该给你一些想法。
设置
存储设置如下所示：
6 个 SATA 驱动器上的 Mdraid RAID6 作为 /dev/md1。该数组用作 LVM2 卷组“vg_arch”的 PV。VG中有多个LV，其中一个是“lv_arch2”，格式为Ext4。
所以我们有：HDD→MD→LVM→Ext4
问题
在对您的 mdraid 阵列 (
/usr/share/mdadm/checkarray -a /dev/md1) 运行检查后，您在 中发现了类似这样的行/var/log/syslog：这里的问题是 RAID 阵列中的某些块已损坏，数据不可信。造成这种情况的不同原因几乎是无限的，但扇区坏了，我们现在必须查明是否有文件存储在那里，如果有，是什么文件。
在我的例子中，数组被分成 50/50，所以 mdraid 不可能知道要使用什么数据。
坏道范围为2684449552-2684449600，共48个。
最好先阅读有关 RAID 恢复的信息，并在尝试恢复时使用覆盖，以免破坏您的数据。摧毁这一切非常容易。
我假设您的阵列已经组装好并且可以正常工作，至少是在只读模式下。我在测试时使用了覆盖，所以我没有错误地向真实数组写入任何内容。本指南只需要只读访问权限。
行业狩猎
首先，我们从内核获得的扇区号是 md 数组的扇区（至少这是我的假设）。这很好，因为我们不需要考虑较低级别的存储堆栈（分区偏移等），这使它更容易一些。
这是我们必须遵循的路径：HDD→MD→LVM→Ext4→file
LVM
我们已经在MD层面了，现在我们需要看看LVM。
LVM 堆栈的底部是物理卷 (PV)。这些被分割成区段，一个或多个区段组成一个逻辑卷 (LV)。物理卷只是底层设备，所以在这种情况下是
/dev/md1.PV 中的数据不直接从扇区 0 开始，而是有一个偏移量。第一个扇区用于 LVM 元数据。我们首先必须计算出范围从 PV 开始到多远：
数据从 PV 中的 2048 个扇区开始。有问题的扇区从
2684449552-2048 = 2684447504LVM 中的扇区开始，到2684449600-2048 = 335555944.接下来我们需要知道 LVM extent 有多大：
每个 LVM 范围有 8192 个扇区。
现在我们可以计算问题开始的程度：
2684447504/8192 = 327691,345703125 extents它是小数，因为该扇区不在精确的 PE 边界上。余数将为我们提供 PE 中的扇区偏移量：
0,345703125*8192 = +2832 sectors下一步是尝试找到使用 PE 327691 的 LV：
我们可以看到 PE 属于 LV
/dev/vg_arch/lv_arch2，并且没有偏移量。如果它有偏移量，我们必须考虑到这一点。文件系统 Ext4
我们现在有足够的信息可以进入文件系统级别。首先，我们必须知道我们正在使用的扇区/块大小：
md 数组使用 512 字节扇区（我有点不确定这是否正确。我基本上只是假设内核在报告错误时使用相同的扇区大小）。
要获取 Ext4 块大小：
文件系统使用 4KiB 块，相当于每个块 8 个扇区。
现在我们必须将 mdadm 扇区号转换为 Ext4 块号，因为它们不相同。为此，我们可以使用以下公式：
在这种情况下，我们有：
因此，在 Ext4 文件系统中，有问题的块范围是 335555938 到 335555944。
文件检查
当我们现在有了块号时，我们可以继续尝试找到存储在那里的文件。这可以使用
debugfs.然后在
debugfs控制台中，使用 open 命令打开文件系统（它必须尚未挂载）：如果您的文件系统很大，此操作可能需要一些时间。
现在我们可以开始测试块是否被使用了。如果幸运的话，坏块没有被任何文件使用。用来
testb blocknumber测试它。对您拥有的每个坏块重复此命令并记录任何使用过的坏块，如下所示：
如果所有块都未使用，您就完成了。恭喜！如果没有，那我们就得继续寻找受影响的文件。
下一步是找到正在使用此块的索引节点：
所以我们有一个受影响的 inode 279577043，让我们找到文件名：
最后，我们找到了受损坏的 mdadm 扇区影响的文件。那不是太难。;-)
最后，运行命令
close并quit退出debugfs。来源
很难找到有关此问题的信息，但以下是我使用最多的站点：
https://serverfault.com/questions/315700/how-to-determine-which-file-inode-occupies-a-given-sector