主页 / server / 问题 / 1155999
Accepted
L. Pinkston
Asked: 2024-03-10 10:28:31 +0800 CST

btrfs 安装错误“无法读取超级块”

  • 772

我在 raid6 中有一个 Synology nas 驱动器，该驱动器出现故障。在电源故障导致存储池崩溃后，我更换了驱动器，并让另外两个驱动器退出了 raid。我能够将所有驱动器移至另一个系统并重建 raid 和 lvm，但 btrfs 文件系统上存在阻止安装的错误。

我已经通过试运行运行了 btrfs 恢复，并显示了一些预期的文件。我目前得到

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 服务，这些服务在重建失败期间仍在运行。

我想我可以暴力破解这棵树下的所有文件名只是为了验证，但是有没有办法强制这片叶子上的标志回到某种形式的可操作状态？

network-attached-storage

2 个回答

  1. 抱歉我的第一条评论。但至少你的问题是你不能信任块级 RAID 的一个很好的例子。人们可能认为恢复 RAID 阵列就是完全恢复所需要做的全部工作，但块级 RAID 并不是 100% 安全，而且由于块级性质，您甚至不会检测到错误。BTRFS 是一个严格的文件系统，几乎所有内容都经过校验和。BTRFS 检测到这些错误的原因是，您的 RAID 故障已破坏了该文件系统上的一些数据。像 EXT4 这样不太严格的文件系统将无法检测到此类错误，或者只会“删除”错误的内容（丢失的文件）。我强烈建议使用备份。

    或许可以“修复”BTRFS 文件系统，但您应该知道，这种修复永远不会恢复丢失的数据。我不推荐这种方法。使用备份。如果您没有备份并且数据对您来说非常重要，那么请咨询专业的数据救援公司。不要尝试使用 BTRFS“恢复”工具，它们在数据安全方面极其危险。

    当您使用备份时，我建议对新文件系统进行以下设置。

    不要使用MDADM，不要使用LVM，只使用BTRFS RAID1。BTRFS内置LVM和RAID功能，在数据保护方面比MDADM+LVM更安全。

    PS 不要使用 BTRFS RAID5 或 RAID6，这些模式是实验性的，使用起来不安全

    • 0
  2. Best Answer
    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 恢复无法恢复文件

    /* 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 文件系统因无效标志而无法安装的奇怪错误情况，但我不建议删除安全检查，除非您绝对确定自己在做什么并愿意接受风险。

    • 0

相关问题