如何修复 btrfs？

Question

我已经搜索了邮件列表并最终完成了Ubuntu 的btrfs页面，但我btrfs 仍然觉得仍然没有完整的修复实用程序（如他们的主页所示）。尽管几个月前它被定为 Oracle 的 Linux 的默认设置，并包含在许多发行版中。

那么，取而代之的是，是否有关于如何修复的故障排除指南btrfs？

否则，将我的备份复制到我的 FS 之上会解决问题吗？（如果需要空间，删除快照？还是删除损坏？）我应该尝试恢复到以前的快照，然后从备份中恢复丢失的文件吗？或者从我的 @ 和 @home 快照恢复丢失的文件？

注意：这是一个一般性问题。我故意省略了我的确切 FS 问题（目前）；我想找到通用/规范的工作流程和故障排除指南。

（好吧，好吧 - 这里有更多细节；））：

我在挂起关机期间断电，因此系统不稳定。系统将启动并运行一段时间，直到它写入足够的数据并冻结。上次我刚刚打开了 Thunderbird。这些需要更多的硬重置和可能更多的损坏。 sudo btrfsck /dev/sda1在一些错误之间波动 - 通常是第一次出现

root 338 inode 7861227 errors 1000
root 338 inode 7904568 errors 1000
root 338 inode 7955174 errors 400
found 46242054144 bytes used err is 1
total csum bytes: 43112400
total tree bytes: 2074640384
total fs tree bytes: 1889853440
btree space waste bytes: 547680627
file data blocks allocated: 110756974592
 referenced 68393684992
Btrfs Btrfs v0.19

oooo，现在它真的很果味（我只希望在parent transid verify failed这里看到......）

parent transid verify failed on 14266105856 wanted 464223 found 464221
parent transid verify failed on 14266105856 wanted 464223 found 464221
Extent back ref already exists for 14261530624 parent 0 root 256 
leaf parent key incorrect 14261751808
bad block 14261751808
Extent back ref already exists for 66455355392 parent 0 root 2 
Extent back ref already exists for 66455257088 parent 0 root 2 
Extent back ref already exists for 14257274880 parent 0 root 2 
block 14262571008 rec extent_item_refs 2, passed 2
block 14262575104 rec extent_item_refs 1, passed 1
block 14262579200 rec extent_item_refs 1, passed 1
Extent back ref already exists for 14262579200 parent 0 root 257 
leaf 14263906304 items 50 free space 132 generation 464224 owner 2
fs uuid 7d049403-cf6e-4b52-a624-32051e1f5b2a
chunk uuid be6f8f93-320c-4465-85d6-f53907698c32
item 0 key (14263341056 EXTENT_ITEM 4096) itemoff 3944 itemsize 51
    extent refs 1 gen 464168 flags 2
    tree block key (8332576 1 0) level 0
    tree block backref root 257
item 1 key (14263345152 EXTENT_ITEM 4096) itemoff 3893 itemsize 51
    extent refs 1 gen 464168 flags 2
    tree block key (8332586 c 8332543) level 0
    tree block backref root 257
failed to find block number 14263525376

（当然，所有内容都进行了大量总结；我从不想用这些细节压倒你:)）

现在我最后的执行让我熟悉了：

parent transid verify failed on 14265458688 wanted 464230 found 464221
parent transid verify failed on 14265458688 wanted 464230 found 464221
parent transid verify failed on 14265458688 wanted 464230 found 464223
btrfsck: root-tree.c:46: btrfs_find_last_root: Assertion `!(path->slots[0] == 0)' failed.

，包括最后的可选随机误差。哦快乐的快乐。请注意，这些verify failed会随着数据写入驱动器而发生变化。

另一个随机错误：

btrfsck: disk-io.c:412: find_and_setup_root: Assertion `!(!root->node)' failed.

Answer 1

帮助回答：

父传输验证失败 14265458688 通缉 464230 找到 464221

可以通过以下方式修复：

$ btrfs-zero-log DEVICE

注意：数据可能会丢失！首先尝试安装：

$ mount -t btrfs -o recovery,nospace_cache,clear_cache DEVICE MOUNTPOINT

如果不能挂载数据，就像它说“坏 fs”：

$ btrfs restore DEVICE DIRECTORY_TO_DUMP_DATA_TO

这是我发送的一封真实但难以理解的电子邮件，以澄清他的解决方案。希望你能做出这个神秘的解释：

电子邮件摘录

回复：问题：如何恢复这个分区？（无法找到符合逻辑的 $hugenum len 4096）

雨果米尔斯 carfax.org.uk> 写道：

在 2013 年 8 月 26 日星期一下午 01:10:54 -0600，Chris Murphy 写道：

2013 年 8 月 26 日上午 11:41，Nick Lee nickle.es> 写道：

几天前在 IRC 上有一个讨论，树根的 bloco 问题可能是磁盘本身或块树/逻辑映射问题的结果。我运行了块恢复，查看了它发现的错误，然后点击写入。（如果它失败了，我将运行一些 photorec，作为副作用的组织损失。）

如果你想的话，我可以在明天我的航班降落后写得更清楚一些。

我只是想知道何时使用各种技术：-o recovery、btrfsck、chunk-recover、zero log。

假设您没有物理设备故障（这是一组不同的工具——mount -odegraded，btrfs dev del missing）。

首先要做的是获取文件系统的 btrfs-image -c9 -t4，并保留一份输出副本以显示 josef。:)

然后从 -orecovery 和 -oro,recovery 开始，几乎可以做任何事情。

如果这些失败，那么在 dmesg 中查找与日志树相关的错误——如果它已损坏且无法读取（或导致崩溃），请使用 btrfs-zero-log。

如果块树有问题——我最近看到的唯一一个是报告“无法映射地址”之类的东西——那么块恢复可能会有用。

在那之后，btrfsck 可能是下一个要尝试的事情。如果选项 -s1、-s2、-s3 有任何成功，那么 btrfs-select-super 将通过用一个有效的替换超级块来提供帮助。如果这没有用，请回退到 btrfsck --repair。

最后，如果扩展区树损坏，则可能需要 btrfsck --repair --init-extent-tree。最后，如果校验和有损坏，还有 --init-csum-tree。

雨果。