btrfs ontop of mdadm raid - 计算损坏扇区的条带以供 raid6check 使用

btrfs ontop of mdadm raid - 计算损坏扇区的条带以供 raid6check 使用

我有一个在 mdadm raid6 上运行 btrfs 的设置,因为 btrfs 的 RAID5/6 代码还不稳定。我想这样我就可以享受快照和校验的好处,但需要克服一些额外的困难,现在我实际上必须克服这些困难,但我遇到了一些问题。

今天早上我的 dmesg 出现了这个问题:

BTRFS error (device md2): bad tree block start, want 28789209759744 have 7611175298055105740
BTRFS info (device md2): read error corrected: ino 0 off 28789209759744 (dev /dev/md2 sector 55198191488)
BTRFS info (device md2): read error corrected: ino 0 off 28789209763840 (dev /dev/md2 sector 55198191496)
BTRFS info (device md2): read error corrected: ino 0 off 28789209767936 (dev /dev/md2 sector 55198191504)
BTRFS info (device md2): read error corrected: ino 0 off 28789209772032 (dev /dev/md2 sector 55198191512)

如果我没有使用 btrfs,这种事情可能会悄悄溜走,所以至少它给我带来了一些好处...所以现在,我应该能够找出哪个磁盘有问题并更换它,对吗?

嗯,mdadm 似乎仅支持使用 raid6check 工具确定故障磁盘,我必须从源代码构建它才能使其在 Debian 上运行,但在我这样做之后,似乎我可以开始做生意了。

唯一的缺点是这个工具似乎非常慢,扫描 1000 个条带需要整整 3 分钟。这意味着扫描组成我的阵列的 15261512 个条带需要超过 31 天的时间。如果可能的话,我想避免这种情况。mdadm 检查/修复要快得多,只需大约 3 天,但不会提供任何有关哪个磁盘可能对此负责的有用信息,所以我不太想使用它。

raid6check 工具似乎支持接受条带号 - 我想知道是否可以计算出要传递给它的条带号,以便我可以让它直接检查磁盘的相关部分。

以下是 raid6check 信息,供参考,如果有帮助:

layout: 2
disks: 8
component size: 8001427603456
total stripes: 15261512
chunk size: 524288

谢谢,任何想法都值得赞赏。

答案1

好吧,在与 Freenode 上的 #linux-raid 上的 JyZyXEL 交谈后,我找到了一种可行的方法。

raid6check 报告总条带数,因此像这样运行它即可查看基本信息,而无需运行完整测试:

./raid6check /dev/md0 0 1

你会得到类似这样的结果:

layout: 2
disks: 8
component size: 8001427603456
total stripes: 15261512
chunk size: 524288

使用 fdisk -l /dev/md0 检查 RAID 中的总扇区数:

Disk /dev/md2: 43.7 TiB, 48008565620736 bytes, 93766729728 sectors

现在计算每个条带的扇区数:

total sectors / total stripes = 93766729728 / 15261512 = 6144

现在,只需将有错误的扇区除以每个条带的扇区数:

error sector = 55198191488/6144 = 8984080

现在运行 raid6check,尝试包括它周围的区域,因为这似乎不准确:

raid6check /dev/md0 8984000 1000

对我来说,这很快产生了许多相关错误,所有错误都指向可能发生故障的同一磁盘:

 Error detected at stripe 8984078, page 100: possible failed disk slot 1: 4 --> /dev/sdj1
 Error detected at stripe 8984081, page 76: possible failed disk slot 4: 4 --> /dev/sdj1

从此时起,您可以采取相应的行动,更换磁盘、运行 SMART 测试、使用 raid6check 的自动修复等。

这可能不是最精确的方法,但我发布它只是为了防止没有其他人提出更好的主意并且有人正在寻找将来可以完成这项工作的方法。

相关内容