我相信我没有理想的正确的文件系统布局来运行 btrfs，我得到的看起来更像是 ext4 文件系统布局。除了 /.snapshots 之外没有子卷
基本上，我有几百台机器，如下所示：
/dev/mapper/system-root 2097152 396120 1230536 25% /
/dev/mapper/system-usr 3670016 1778496 1434560 56% /usr
/dev/mapper/system-boot 524288 128848 202320 39% /boot
/dev/mapper/system-root 2097152 396120 1230536 25% /.snapshots
/dev/mapper/system-root 2097152 396120 1230536 25% /srv
/dev/mapper/system-root 2097152 396120 1230536 25% /root
/dev/mapper/system-opt 2097152 754016 978080 44% /opt
/dev/mapper/system-tmp 1048576 4352 751936 1% /tmp
/dev/mapper/system-home 10485760 1312884 8594316 14% /home
/dev/mapper/system-var 8388608 2695188 5342956 34% /var
/dev/mapper/system-splunk 8388608 3648160 4311040 46% /opt/splunk
/dev/mapper/system-zypp 1048576 31236 725500 5% /var/cache/zypp
升级到 Sles15 - SP3 并遇到了一个非常严重的错误，其中一些events_unbound线程耗尽了所有 CPU，性能向我展示了这是由 btrfs 维护工作引起的，并进一步深入研究，我发现它在 2021 年进行了修补（但可能没有向后移植到 sles15）
除此之外，此问题的解决方法似乎只是为所有文件系统提供足够的磁盘，以便它们每个都可以执行btrfs balance start --full-balance /path/to/thing
我发现我必须为许多卷添加空间才能做到这一点（即使是那些报告有 50% 可用空间的卷）。
所以，我想知道的是，我是否应该进行监控以确保我能够在每个文件系统上进行全面平衡，并且除了实际进行平衡之外，是否有一种方法可以找到一个好的阈值每个文件系统上的理想可用空间量，因此如果达到一定百分比的满载（或另一个有意义的指标），我可以发起某种事件并在它开始占用我的 CPU 之前对其进行修复？