如何修复btrfs？[关闭]

我已经拖曳了邮件列表，最后在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.

为了帮助回答：

父级半态验证失败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>写道：

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

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

几天前在IRC上进行了讨论，树根的bloco问题很可能是磁盘本身或块树/逻辑映射问题所致。我运行了块恢复，查看了发现的错误，然后单击写入。（如果失败，我将进行一些光记录，因为失去组织而产生副作用。）

如果您愿意，明天飞机降落后，我可以写出更清晰的内容。

我只是好奇何时使用各种技术：-o恢复，btrfsck，块恢复，零日志。

假设您没有物理设备故障（这是另一套工具-mount -odegraded，缺少btrfs dev del）。

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

然后从-orecovery和-oro开始，恢复几乎所有内容。

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

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

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

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

雨果