btrfs filesystem defragment用于在线整理指定目录或文件的碎片，通过写时复制重写为连续块以降低读取延迟，需读写挂载且不跨子卷；balance则重分布数据与元数据块，解决全局碎片、空间不均及元数据耗尽问题。
用 btrfs filesystem defragment 整理单个目录或文件的碎片
这个命令不是整理整个文件系统，而是对指定路径下的文件做在线 defrag（写时复制重写），适用于频繁修改大文件的场景，比如数据库日志、虚拟机镜像。它不移动数据块位置，而是把碎片化的文件重新写成连续块，降低后续读取延迟。
常见错误现象：btrfs filesystem defragment 对只读挂载点报错 Operation not supported；对压缩挂载选项（如 compress=zstd）启用时，部分文件可能跳过整理（内核会自动跳过已压缩页）。
- 必须挂载为读写模式，且不能是
ro或degraded状态 - 加
-r递归处理子目录，但不会跨子卷（subvolume是独立命名空间） - 加
-v可看每个文件是否被实际重写（输出含defragged字样才算成功） - 避免在高 I/O 负载时运行，它会触发大量写入，可能加剧磁盘压力
示例：sudo btrfs filesystem defragment -r -v /var/lib/libvirt/images
用 btrfs balance 重分布数据块和元数据，解决全局碎片与空间不均
balance 不是“整理碎片”本身，而是通过重新写入所有数据块和元数据块，间接达成碎片减少 + RAID 均衡 + 容量释放（比如删掉旧 chunk）的效果。它真正影响的是文件系统底层的逻辑块布局，而不是单个文件的物理连续性。
容易踩的坑：btrfs balance 默认会重写全部数据，耗时长、I/O 高；若中途失败（如断电），可能卡在 balance in progress 状态，需用 btrfs balance pause + resume 恢复，而非直接重启。
- 加
-dusage=5只平衡使用率低于 5% 的数据 chunk（适合腾出空间后清理空闲 chunk） - 加
-musage=90只平衡元数据中使用率高于 90% 的 chunk（防元数据耗尽导致无法创建新文件） - 加
-sconvert=raid1可在 balance 过程中变更元数据 RAID 级别（如从 single 升级为 raid1） - 务必搭配
-v观察进度，用btrfs filesystem usage /mount/point对比前后 chunk 分布
示例：sudo btrfs balance start -dusage=10 -musage=80 -v /mnt/btrfs_data
群晖 NAS 上点选“文件系统碎片整理”背后调用的是什么？
群晖界面里那个按钮，本质是封装了 btrfs filesystem defragment -r，但它做了严格限制：只允许在存储池状态为 normal、无快照正在创建、且未启用 SSD Trim 冲突选项时执行。它不会调用 balance，也不会处理元数据碎片。
真实使用场景有限：仅适合小规模、以小文件读写为主的共享文件夹（如文档、配置文件）。对大块顺序 I/O 场景（如视频转码缓存）几乎无效，反而可能因反复 rewrite 加速 SSD 磨损。
- 它默认跳过所有子卷（
@docker、@appstore等系统子卷不会被触碰） - 执行期间无法创建新快照，已有快照会增大占用（因为 defrag 触发 CoW）
- 若看到“整理了 0 个文件”，大概率是该目录下所有文件都已被标记为
NO_COW（如数据库文件被应用直写）
什么时候该用 defragment，什么时候该用 balance？
二者目标不同：defragment 是“让单个文件读得更快”，balance 是“让整个文件系统更健壮、更均衡”。多数情况下，你根本不需要主动运行前者 —— Btrfs 的延迟分配和 CoW 天然抑制文件级碎片；而后者在扩容、RAID 调整、或发现 btrfs filesystem usage 显示某块设备使用率严重倾斜时才真正必要。
一个常被忽略的复杂点：defragment 无法修复元数据碎片，而元数据高度碎片化（表现为 metadata used 接近 100%）会导致新建子卷、快照失败，此时必须靠 balance -m 解决，不是加内存或重启能绕过的。
