我查遍了邮件列表，最后完成了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
哦哦，现在果味十足了（我只想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.
答案1
帮忙解答一下：
父级 transid 验证失败 14265458688 通缉 464230 找到 464221
可以通过以下方式修复：
$ btrfs-zero-log DEVICE
笔记：数据可能会丢失！首先尝试安装：
$ mount -t btrfs -o recovery,nospace_cache,clear_cache DEVICE MOUNTPOINT
如果无法像“bad fs”那样挂载数据：
$ btrfs restore DEVICE DIRECTORY_TO_DUMP_DATA_TO
这是我发送的一封真实的电子邮件，虽然很难理解，但目的是澄清他的解决方案。希望你能明白这个神秘的解释：
摘录电子邮件
回复：问题：如何恢复该分区？ （无法找到逻辑 $hugenum len 4096）
雨果·米尔斯 carfax.org.uk> 写道：
2013 年 8 月 26 日星期一 01:10:54PM -0600，Chris Murphy 写道：
2013 年 8 月 26 日上午 11:41，Nick Lee nickle.es> 写道：
几天前，IRC 上有一个讨论，树根的 bloco 问题可能是磁盘本身问题或块树/逻辑映射问题的结果。我运行了块恢复，检查了它发现的错误，然后点击写入。 （如果失败了，我将运行一些 photorec，作为副作用，失去组织。）
如果你愿意的话，我可以在明天航班降落后写更清楚的内容。
我只是好奇何时使用各种技术：-o recovery、btrfsck、chunk-recover、零日志。
假设您没有物理设备故障（这是一组不同的工具 - mount -odegraded、btrfs dev del 缺失）。
首先要做的是获取文件系统的 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。
雨果.