我在 raid6 中有一个 synology nas 驱动器,其中一个驱动器发生故障。我更换了该驱动器,并在电源故障导致存储池崩溃后将另外两个驱动器从 raid 中踢出。我能够将所有驱动器移至另一个系统并重建 raid 和 lvm,但 btrfs 文件系统上存在阻止安装的错误。
我已经运行了 btrfs restore with dry run,并出现了一些预期的文件。我目前得到
mount error
can't read superblock on /dev/mapper/vg1-volume_1.
这是最后一个错误消息,以及无法读取超级块。来自 dmesg
BTRFS info (device dm-1): using crc32c (crc32c-intel) checksum algorithm
BTRFS info (device dm-1): using free space tree
BTRFS critical (device dm-1): corrupt leaf: root=1 block=503087104 slot=23, invalid root flags, have 0x400000000 expect mask 0x1000000000001
BTRFS error (device dm-1): read time tree block corruption detected on logical 503087104 mirror 1
BTRFS critical (device dm-1): corrupt leaf: root=1 block=503087104 slot=23, invalid root flags, have 0x400000000 expect mask 0x1000000000001
BTRFS error (device dm-1): read time tree block corruption detected on logical 503087104 mirror 2
BTRFS error (device dm-1): open_ctree failed
我能清除的最后一个错误来自 https://unix.stackexchange.com/questions/369520/btrfs-super-recover-says-all-superblocks-are-good-but-mount-disagrees
零日志清除了第一个错误。
btrfs rescue super-recover -v /dev/mapper/vg1-volume_1
All Devices:
Device: id = 1, name = /dev/mapper/vg1-volume_1
Before Recovering:
[All good supers]:
device name = /dev/mapper/vg1-volume_1
superblock bytenr = 65536
device name = /dev/mapper/vg1-volume_1
superblock bytenr = 67108864
device name = /dev/mapper/vg1-volume_1
superblock bytenr = 274877906944
[All bad supers]:
All supers are valid, no need to recover
btrfs check --check-data-csum
Opening filesystem to check...
Checking filesystem on /dev/mapper/vg1-volume_1
UUID: c9d2c563-30cb-4b27-b29a-d5f2642597d8
[1/7] checking root items
[2/7] checking extents
Invalid key type(BLOCK_GROUP_ITEM) found in root(202)
ignoring invalid key
--------There are a lot of these
Invalid key type(BLOCK_GROUP_ITEM) found in root(202)
ignoring invalid key
[3/7] checking free space tree
[4/7] checking fs roots
[5/7] checking csums against data
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 37552772378624 bytes used, no error found
total csum bytes: 2551494312
total tree bytes: 7828389888
total fs tree bytes: 4063068160
total extent tree bytes: 754450432
btree space waste bytes: 1181718069
file data blocks allocated: 37548545822720
referenced 37710498009088
btrfs inspect-internal dump-super /dev/mapper/vg1-volume_1
superblock: bytenr=65536, device=/dev/mapper/vg1-volume_1
---------------------------------------------------------
csum_type 0 (crc32c)
csum_size 4
csum 0x5be2c7ca [match]
bytenr 65536
flags 0x1
( WRITTEN )
magic _BHRfS_M [match]
fsid c9d2c563-30cb-4b27-b29a-d5f2642597d8
metadata_uuid c9d2c563-30cb-4b27-b29a-d5f2642597d8
label 2019.10.19-07:46:08 v24922
generation 2838041
root 29818880
sys_array_size 129
chunk_root_generation 2793730
root_level 1
chunk_root 21020672
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 39958383427584
bytes_used 37552772378624
sectorsize 4096
nodesize 16384
leafsize (deprecated) 16384
stripesize 4096
root_dir 6
num_devices 1
compat_flags 0x8000000000000000
compat_ro_flags 0x3
( FREE_SPACE_TREE |
FREE_SPACE_TREE_VALID )
incompat_flags 0x16b
( MIXED_BACKREF |
DEFAULT_SUBVOL |
COMPRESS_LZO |
BIG_METADATA |
EXTENDED_IREF |
SKINNY_METADATA )
cache_generation 18446744073709551615
uuid_tree_generation 2838039
dev_item.uuid 3ce7be34-1a1f-42aa-9330-186edef4841e
dev_item.fsid c9d2c563-30cb-4b27-b29a-d5f2642597d8 [match]
dev_item.type 0
dev_item.total_bytes 39958383427584
dev_item.bytes_used 38619297349632
dev_item.io_align 4096
dev_item.io_width 4096
dev_item.sector_size 4096
dev_item.devid 1
dev_item.dev_group 0
dev_item.seek_speed 0
dev_item.bandwidth 0
dev_item.generation 0
我不知道该怎么做,因为很多选项都有潜在的破坏性。当我将驱动器放在只读 synology 池中时,我可以下载所有关键文件,但无法找出为什么它不能安装在常规 Linux 机器上。
添加:
我做了更多的研究,并在邮件列表中发现了有关丢弃损坏叶子的讨论。(https://lore.kernel.org/linux-btrfs/[电子邮件保护]/T/)
我已经从 dmseg 中删除了叶子
btrfs ins dump-tree --follow -b 503087104 /dev/mapper/vg1-volume_1
并发现两片有问题的叶子
item 23 key (2350 ROOT_ITEM 0) itemoff 12022 itemsize 439
generation 2838037 root_dirid 256 bytenr 502956032
byte_limit 0 bytes_used 81920
last_snapshot 0 flags 0x400000000(none) refs 1
drop_progress key (0 UNKNOWN.0 0) drop_level 0
level 1 generation_v2 2838037
uuid 7d68b7fc-ce56-ea45-8790-420407a74ad2
parent_uuid 00000000-0000-0000-0000-000000000000
received_uuid 00000000-0000-0000-0000-000000000000
ctransid 2838037 otransid 241922 stransid 0 rtransid 0
ctime 1708421965.207146578 (2024-02-20 04:39:25)
otime 1643063079.756142504 (2022-01-24 17:24:39)
stime 0.0 (1969-12-31 19:00:00)
rtime 0.0 (1969-12-31 19:00:00)
item 24 key (2350 ROOT_BACKREF 257) itemoff 11990 itemsize 32
root backref key dirid 256 sequence 113 name @synologydrive
item 25 key (2351 ROOT_ITEM 0) itemoff 11551 itemsize 439
generation 2836999 root_dirid 256 bytenr 34504704
byte_limit 0 bytes_used 16384
last_snapshot 0 flags 0x400000000(none) refs 1
drop_progress key (0 UNKNOWN.0 0) drop_level 0
level 0 generation_v2 2836999
uuid 131923b8-a88e-0c45-b91f-a43baed3487c
parent_uuid 00000000-0000-0000-0000-000000000000
received_uuid 00000000-0000-0000-0000-000000000000
ctransid 2836999 otransid 268246 stransid 0 rtransid 0
ctime 1708303323.350998786 (2024-02-18 19:42:03)
otime 1647641350.503037199 (2022-03-18 18:09:10)
stime 0.0 (1969-12-31 19:00:00)
rtime 0.0 (1969-12-31 19:00:00)
从错误消息来看,问题似乎是标志,当我在叶子上转储树时,它们都显示其下有大量有效块。大多数文件名似乎围绕着在重建失败期间仍在运行的 synology nas 服务。
我想我可以强制执行这棵树下的所有文件名只是为了验证,但是有没有办法强制将此叶子上的标志恢复到某种可操作状态?
答案1
抱歉,这是我的第一条评论。但至少您的问题是一个很好的例子,说明了为什么您不能信任块级 RAID。有人可能会认为恢复 RAID 阵列就是完全恢复所需的全部操作,但块级 RAID 并非 100% 安全,而且由于块级性质,您甚至无法检测到错误。BTRFS 是一个严格的文件系统,几乎所有内容都经过校验和。您的 BTRFS 检测到这些错误的原因是,您的 RAID 故障破坏了此文件系统上的某些数据。不太严格的文件系统(如 EXT4)无法检测到这些类型的错误,或者只会“删除”错误的内容(您丢失的文件)。我强烈建议使用备份。
也许可以“修复” BTRFS 文件系统,但您应该知道,这种修复永远不会让您恢复丢失的数据。我不推荐这种方法。使用备份。如果您没有备份,并且数据对您非常重要,请咨询专业的数据救援公司。不要尝试使用 BTRFS“恢复”工具,它们在数据安全方面极其危险。
当您使用备份时,我建议对新文件系统进行以下设置。
不要使用 MDADM,不要使用 LVM,只使用 BTRFS RAID1。BTRFS 具有内置的 LVM 和 RAID 功能,在数据保护方面比 MDADM+LVM 更安全。
PS 不要使用 BTRFS RAID5 或 RAID6,这些模式尚处于实验阶段,使用起来不安全
答案2
BTRFS critical (device dm-1): corrupt leaf: root=1 block=503087104 slot=23, invalid root flags, have 0x400000000 expect mask 0x1000000000001
由于 tree-checker.c 中的以下检查,btrfs restore 无法恢复文件
/* Flags check */
if (unlikely(btrfs_root_flags(&ri) & ~valid_root_flags)) {
generic_err(leaf, slot,
"invalid root flags, have 0x%llx expect mask 0x%llx",
btrfs_root_flags(&ri), valid_root_flags);
return -EUCLEAN;
}
如果注释掉这项检查并重新编译 btrfs-progs,则恢复程序将能够将文件系统未损坏的部分复制到新驱动器。
虽然这个“修复”可以解决由于无效标志而导致我的 btrfs 文件系统无法挂载的奇怪错误情况,但我不建议删除安全检查,除非你绝对确定自己在做什么并且愿意承担风险。