如何修复 btrfs 范围问题

Question

我想我被 btrfs 中的一个已知错误击中了：

https://www.spinics.net/lists/linux-btrfs/msg60984.html

当然，错误消息看起来很相似。如果是同样的问题，似乎有点不幸的是，针对一个 2 年之久的问题的修复程序尚未移植到 V4.9 稳定内核中（这是 Debian 9 使用的内核）

我现在处于文件系统 inode 之一存在范围问题的情况（如 所报告的btrfs check）：

root 257 inode 2607184 errors 100, file extent discount
Found file extent holes:
       start: 0, len: 81920

似乎没有太多关于如何摆脱这种情况的建议或文档（幸运的是我确实有相关文件系统的备份，所以最坏的情况可能会重新格式化和恢复）

似乎btrfs check --repair只是一遍又一遍地循环打印相同的错误，而没有实际修复它。

有没有办法修复现有的文件系统，或者我最好重新创建它并恢复备份？

Answer 1

我认为root 257是指子卷 ID，然后inode 2607184指向有问题的 inode。我会尝试删除（取消链接）链接到 inode 的每个路径。

1. 挂载子卷：

   mount /dev/sdXN -o subvolid=257 /mnt/mountpoint
   

2. 找到具有匹配 inode 编号的每个条目：

   find /mnt/mountpoint -xdev -inum 2607184
   

3. 调查对象。希望你能负担得起删除它们。

   • （我不确定它是否可能是您的情况下的目录）。如果它是一个目录，我怀疑它的列表可能不完整。
     1. 将其内容（如果有）移动到另一个新目录（创建具有相同所有权、权限的目录）；删除旧目录；mv新目录改为旧名称。
     2. 与您的备份相比，还原丢失的对象。
   • 如果是一个或多个文件 –
     1. 将它们全部删除。
     2. 从备份中恢复文件。

4. 卸载：

   umount /mnt/mountpoint
   

5. 检查文件系统。有问题的 inode 应该不复存在了。

或者，您可以删除整个子卷。这似乎有点矫枉过正，但它应该摆脱有问题的 inode。

1. 挂载文件系统的根目录：

   mount /dev/sdXN -o subvol=/ /mnt/mountpoint
   

2. 列出子卷：

   btrfs subvolume list /mnt/mountpoint
   

   并找到 ID 为 257 的那个。

3. 删除子卷：

   btrfs subvolume delete -c /mnt/mountpoint/path/to/the/subvolume/with/ID/257
   

4. 卸载：

   umount /mnt/mountpoint
   

5. 检查文件系统。有问题的 inode 应该不复存在了。

6. 从备份中恢复数据。