btrfs问题记录

记录btrfs 文件系统问题

问题记录

今天在运维工作中遇到一个问题。期初是用户报MQ软件无法使用了。

检查时发现MQ的是安装过的，但是原本应该有mq安装后文件的/opt目录下空的。

问题环境是一个suse12 的， 根目录使用了btrfs的文件系统模式。检查问题时发现根目录空间满了。

但是使用du -sh * 查看根目录准备释放空间时发现当时根目录下使用的空间并没有到达25G的上限。

从现象上看就是由于opt目录下文件丢失，导致的MQ失效。但是还有一个问题，现在根目录满了，但是实际上使用的空间并没有那么多。

开始想到的对策是重装mq， 开始并没有将两个问题合到一起去看待， 只是由于重装软件是需要空间的，所以先解决这个文件系统满了的问题。

在释放文件系统空间时 ，先想到的办法是清空之前的文件系统snapshot，环境的根目录是btrfs的，这种文件系统模式是有自动创建文件系统镜像的功能，而他生成的镜像如果比较多的话也会占用相当的根目录空间。
但是在清理时发现该环境的snapsho是空的，而且/.snapshots目录也是空的，正常情况下应该有grub-snapshot.cfg文件。

至此，我发现根目录下有些目录变成了空的，同时，根目录下的空间被莫名其妙的占用掉了。

这个问题困扰了我一段时间，直到我打开了/etc/fstab文件。这里我发现有很多自动挂载的fs信息被注销掉了，其中就包括/opt 和/.snapshots 这两个目录

此时我想到了btrfs的另一个功能subvolume。

这个功能是让btrfs还能再细分成多个更小一级的子卷，这个功能可以和前文的snapshot搭配，对特定的重点目录进行备份。这些subvolume一起使用整个fs的空间。

至此，我将两个问题联系了起来， 推测是由于这些subvolume被注释掉了，导致相应的fs没有被挂载，以至于mq软件异常，无法使用。也是由于这些占用了相当空间的subvolume没有被挂载，导致这些subvolume占用的空间没有被du -sh 这个命令检测到，出现了这个文件系统满了，却找不到是什么东西占用了空间的问题。

解决方法

将/etc/fstab 下被注释的文件系统都取消注释，然后重新启动环境，或者手动进行挂载。
重启完成后，/.snapshots 和/opt目录下的文件均恢复正常，mq已恢复使用。
使用snapper delete 指令删除多余的文件系统快照后， 空间也得以释放。

后记

1. btrfs中自动生成的subvolume不能贸然解除挂载。
2. 各个subvolume虽然各自独立但是在系统层面是共用的整个btrfs的空间，是否有办法能给subvolum分配独立的空间，这个待查。
3. btrfs这个文件系统模式subvolume和snapshot结合确实可以增加文件的安全性，但是同时也会占用相当的空间。
4. btrfs和suse的结合还不错， 在通过yast2 进行一些操作时会自动触发snapshot进行快照，用作后续回退， 尤其在disk调整方面还是有意义的。
5. 功能虽好，但目前和现有环境的结合方面还有待学习。