SDB:BTRFS

这篇文章覆盖了有关 BTRFS 文件系统诊断、修复的步骤。BTRFS 是 openSUSE Leap、openSUSE Tumbleweed 和 openSUSE Kubic 的默认文件系统。

默认子卷

有关 usr merge 造成的文件系统结构变更的信息，详见：采取 UsrMerge 措施的理由

openSUSE 默认为根分区启用 btrfs 文件系统和 snapshot （文件系统快照）。文件系统快照允许你在应用更新或备份文件后，快速回滚系统至某一时刻（某一快照）。Snapshot 的管理方法是简单易懂的，你可以参考 SDB:Snapper Tutorial 获得更多信息。

在使用快照回滚系统时，你需要确保用户的主目录（/home）, 网络和 FTP 服务器内容或日志文件在回滚的过程中不会被覆写或丢失。这可以通过在根文件系统上使用 Btrfs 子卷来实现。用户自建的子卷默认被排除在快照之外。openSUSE 上默认的根文件系统设置是由 YaST 在安装期间配置的，它包含以下子卷。它们被排除在快照之外，原因如下：

   /boot/grub2/i386-pc, /boot/grub2/x86_64-efi, /boot/grub2/powerpc-ieee1275, /boot/grub2/s390x-emu

对于引导加载器的回滚是不受支持的。上面列出的目录是特定架构的。前两个目录会出现在 AMD64/Intel 64 架构的机器上，后两个目录会出现在 IBM POWER 和 IBM Z 系统上。

   /home

如果 /home 分区不是以一个单独的分区而存在，则它会被自动排除在快照之外以避免因回滚造成的数据丢失。

   /opt

第三方产品的安装目录经常是 /opt 。它被排除在快照之外以避免因为回滚而造成卸载应用。

   /root

这是 root 用户的家目录，因为与 /home 一样的原因而被排除在快照之外。

   /srv

包含了网络和 FTP 服务的数据。它会被自动排除在快照之外以避免数据丢失。

   /tmp

该目录包含了应用程序产生的临时文件和缓存文件，它被排除在快照之外。

   /usr/local

在手动安装应用时会使用到该目录。它被排除在快照之外以避免因为回滚而造成卸载应用。

   /var

这个文件夹包含了各式各样的文件，如日志文件、临时缓存、存放于 /var/opt 的第三方产品，并且是许多虚拟机镜像和数据库默认的存储位置。因此安装系统时，YaST 创建该子卷让许多数据避免在系统回滚的过程中被损坏，并默认关闭了写时复制（Copy-On-Write）的功能。

旧的 /var/* 子卷布局 (2018年一月之前)

该小节描述的内容对应的 openSUSE 版本过于老旧，不再提供中文译文支持。

压缩的 BTRFS 文件系统

在 Leap 或 Tumbleweed ，压缩 BTRFS 文件系统是受支持的。使用 compress 或 compress-force 选项，选择压缩算法，lzo 或 zlib（默认）。zlib 压缩有更高的压缩率，而 lzo 更快，占用的 CPU 负荷更少。例如：

   mount -o compress /dev/sdx /mnt

如果你创建了一个文件，并对其进行了写入，而压缩的结果大于或等于未压缩的大小，Btrfs 将在未来永远跳过对这个文件的写入操作的压缩。如果你不喜欢这种行为，可以使用 compress-force 选项。这对于有一些初始未压缩数据的文件来说是很有用的。

注意，压缩只对新建文件有效。当用 compress 或 compress-force 选项挂载文件系统时，未经压缩而写入的旧文件不会被压缩。此外，具有 nodatacow 属性的文件永远不会被压缩它们的程度：

   chattr +C FILE
   mount -o nodatacow  /dev/sdx /mnt

关于加密，这与任何压缩无关。在你向这个分区写入一些数据后，打印出细节：

   btrfs filesystem show /mnt
   btrfs filesystem show /mnt
   Label: 'Test-Btrfs'  uuid: 62f0c378-e93e-4aa1-9532-93c6b780749d
           Total devices 1 FS bytes used 3.22MiB
         devid    1 size 2.00GiB used 240.62MiB path /dev/sdb1

如果你想让它成为永久性的，在 /etc/fstab 配置文件中添加 compress 或 compress-force 选项：

   UUID=1a2b3c4d /home btrfs subvol=@/home,compress 0 0

检查空闲空间

通常使用 df 命令检查文件系统的使用情况。在一个 Btrfs 文件系统中，df 命令的输出结果可能具有误导性，因为除了原始数据分配的空间外，Btrfs 文件系统还为元数据分配和使用空间。

因此，一个 Btrfs 文件系统可能报告没有空间了，即使它看起来还有很多空间可用。在这种情况下，所有分配给元数据的空间都被用完了。使用下面的命令来检查 Btrfs 文件系统上的已用和可用空间。

btrfs filesystem show

   sudo btrfs filesystem show /
   Label: 'ROOT'  uuid: 52011c5e-5711-42d8-8c50-718a005ec4b3
           Total devices 1 FS bytes used 10.02GiB
           devid    1 size 20.02GiB used 13.78GiB path /dev/sda3

显示文件系统的总大小和它的使用情况。如果最后一行的这两个值相符，说明文件系统的所有空间都已被分配。

btrfs filesystem df

   sudo btrfs filesystem df /
   Data, single: total=13.00GiB, used=9.61GiB
   System, single: total=32.00MiB, used=16.00KiB
   Metadata, single: total=768.00MiB, used=421.36MiB
   GlobalReserve, single: total=144.00MiB, used=0.00B

显示文件系统的分配（总）和使用的空间值。如果元数据的总空间和已用空间的值几乎相等，说明元数据的所有空间已经被分配。

btrfs filesystem usage

   sudo btrfs filesystem usage /
   Overall:
       Device size:                  20.02GiB
       Device allocated:             13.78GiB
       Device unallocated:            6.24GiB
       Device missing:                  0.00B
       Used:                         10.02GiB
       Free (estimated):              9.63GiB      (min: 9.63GiB)
       Data ratio:                       1.00
       Metadata ratio:                   1.00
       Global reserve:              144.00MiB      (used: 0.00B)

                Data     Metadata  System
   Id Path      single   single    single   Unallocated
   -- --------- -------- --------- -------- -----------
    1 /dev/sda3 13.00GiB 768.00MiB 32.00MiB     6.24GiB
   -- --------- -------- --------- -------- -----------
      Total     13.00GiB 768.00MiB 32.00MiB     6.24GiB
      Used       9.61GiB 421.36MiB 16.00KiB

显示类似于前两个命令的组合的数据。

更多信息请参考 man 8 btrfs-filesystem 和 https://btrfs.wiki.kernel.org/index.php/FAQ

磁盘空间因为 Snapper 不足

如果 Btrfs 文件系统上运行着 Snapper ，“No space left on device” 的错误信息通常是因为创建了过多的子卷。你可以使用 snapper 删除一些快照，然而，快照不会被立即删除，可能不会释放出你需要的那么多空间。使用 snapper 删除快照：

打开一个终端。
在终端中输入 btrfs filesystem show

sudo btrfs filesystem show
Label: none uuid: 40123456-cb2c-4678-8b3d-d014d1c78c78
 Total devices 1 FS bytes used 20.00GB
 devid 1 size 20.00GB used 20.00GB path /dev/sda3

然后键入

sudo btrfs fi balance start </mountpoint> -dusage=5

这个命令试图重新定位空的或接近空的数据块中的数据，允许空间被回收并重新分配给元数据。这可能需要一些时间（对于1TB来说需要很多小时），尽管在此期间系统是可用的。

使用 snapper 列出子卷

sudo snapper -c root list

删除一个或多个子卷

sudo snapper -c root delete snapshot_number(s)

确保你删除的是最旧的子卷，子卷的创建时间越早，占用的空间越多。

如何修复一个损坏/无法挂载的 Btrfs 文件系统

下面是有关任何重要的 Btrfs 文件系统问题，尤其是无法挂载的情况的推荐解决步骤。阅读 dmesg 或 syslog 可能帮助你识别你需要跳过哪一步来修复一个特定的问题，但原始的步骤通常是有用的，无论如何，btrfs scrub 是一个非常安全的修复工具。

启动到另一个合适的系统，例如救援终端、不同安装位置的 openSUSE 、LiveCD 或一个 openSUSE 的安装 DVD。你正在运行的 openSUSE 版本的安装 DVD 通常是个好选择，因为它肯定会使用相同的内核/btrfs版本。最近的 Tumbleweed 磁盘可能更好，因为它将包括更新的 kernel/btrfs
进入一个合适的终端，并确保你具有 root 权限
尝试将你的分区挂载到 /mnt ，确认它是否是真的损坏

mount /dev/sda1 /mnt

如果成功挂载，你确定它真的损坏了吗？如果是，运行下列指令：

btrfs scrub start /mnt

scrub 系统，然后

btrfs scrub status /mnt

然后监视它

如果无法挂载，尝试 scrub 设备，以防万一

btrfs scrub start /dev/sda1

然后

btrfs scrub status /dev/sda1

监视它。一旦完成，尝试挂载，如果成功，你已经修复了问题。

如果 scrub 不是一个选择，或无法解决问题：

then instead try mount -o usebackuproot

mount -o usebackuproot /dev/sda1 /mnt

注意： 以上所有的步骤都被认为是安全的，应该不会对磁盘进行破坏性的改变。如果上述步骤不能解决你的问题，你可以继续下面的步骤，但情况严重到足以证明有必要请提交一份错误报告！

运行 "btrfs check <device>"

btrfs check /dev/sda1

这不会有帮助，但要把日志保存在某个地方，它对错误报告会很有用。

认真考虑运行 "btrfs restore <device> <somewhereto copy data>"

btrfs restore /dev/sda1 /mnt/usbdrive

这不会修复任何东西，但它会扫描文件系统，并恢复所有它能恢复的东西到挂载的设备。如果你的 btrfs 问题实际上是由硬件故障而不是 btrfs 故障引起的，这就特别有用。

运行 "btrfs rescue super-recover <device>"

btrfs rescue super-recover /dev/sda1

然后尝试正常挂载设备。如果能成功，就不要再进行下去了。

运行 "btrfs rescue zero-log <device>"

btrfs rescue zero-log /dev/sda1