btrfs 挂载错误“无法读取超级块”

btrfs 挂载错误“无法读取超级块”

我在 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 文件系统无法挂载的奇怪错误情况,但我不建议删除安全检查,除非你绝对确定自己在做什么并且愿意承担风险。

相关内容