我的系统（openSUSE 42.1 64bit btrfs）在重启后提示设备上没有剩余空间。几天前，我使用 yast 进行了系统更新。其中 3 个（多媒体内容）无法安装，所以我决定再次开始更新，一切顺利。第二天我重启了系统。今天我尝试通过 ssh 进行更新，发现了这个错误。
系统可以 ssh 连接到其他系统，但无法 ping 通。甚至无法执行 snapper 回滚，因为设备上没有剩余空间。我检查了 df -h 和 df -i，但剩余空间和 inode 足够。可能是什么问题？我应该检查什么？
系统错误和 df -h 和 df -i 的屏幕截图（抱歉质量较差）
答案1
除了许多其他违反良好品味的行为外，btrfs 还破坏了命令的实用性df，因为它有一些受限制的“元数据”空间，不会显示在任何常规报告中，并且需要不时轻轻摇晃以使所有小块落到底部并在顶部留出更多空间……或者其他同样无聊的事情。为了更好地了解您的 btrfs 卷的运行情况，您需要使用 btrfs 自己的卷 df，当然，它位于 之下btrfs filesystem，因此您需要运行btrfs f df- 然后，由于枚举文件系统是一个难题，您需要手动指定文件系统中某处的路径，因此您最终会得到btrfs f df /path/to/filesystem。
接下来，试着弄清楚它告诉你了什么。实际上，我们将跳过这一步，因为它需要博士学位和五分之一的 OP 朗姆酒。相反，只需比较每行的total和used值。这里没有裤腰带“使用率”列 - 甚至没有对齐的列！确实没有！像计算机一样阅读这些行。
如果常客df说你有足够的空间，那么队伍Data就会显示正常；卑鄙的人Metadata可能会杀了你。
要纠正这个问题，您需要执行重新平衡。虽然我确信这是一个非常复杂且必要的操作，但想到一个高度先进的 21 世纪文件系统竟然会重现 20 世纪 70 年代末设计时就已经过时的文件系统最令人烦恼的问题之一，我感到很有趣，更糟糕的是，不定期执行手动维护不仅会造成性能问题，还会将其提升为实际可用性问题！
要执行纯元数据重新平衡，您需要运行此命令然后等待一段时间：
btrfs balance start -v -dusage=0 /path/to/filesystem
完成后，当您重新运行时btrfs f df /path/to/filesystem，您的元数据应该看起来消耗得少了很多。
如果这不能解决问题，那么还有更多关于清除 btrfs 文件系统已满问题的各种方法的信息（和更少的讽刺）马克·梅林，但除了重新平衡元数据之外，我从未做过任何其他事情来恢复某种程度的理智。