我刚刚买了一个 SSD，想迁移我当前的 Ubuntu 安装以利用其性能。
因此我启动了 Ubuntu Live CD，挂载了源（ext4）和目标（SSD，btrfs已挂载compress-force=zlib,nodatacow,noatime,rw,ssd）驱动器，然后开始使用 rsync 复制文件：
sudo rsync -av --exclude=/home/ '/media/username/source/' '/media/username/target'
# /home stays on HDD for now
Rsync 顺利完成了任务。文件数量相似（平均约 120 万个文件，通过右键单击 > Nautilus 上的属性获得的数量），但生成的副本为 31GB，远大于只有 18GB 的源文件。
通过各种方法检查尺寸：
df- 右键单击 > 属性
btrfs filesystem df- 猴面包树
所有结果都相似，但来源要小得多。
我知道，当 COW 开启时，btrfs 会使用某种元数据日志和文件的“影子副本”。但是 COW 是关闭的，即使开启了，第一批数据加上 31GB 中的 12GB 也不可能是元数据；对吧？oo
知道到底发生了什么吗？或者更好的是，如何解决它？
答案1
默认情况下，btrfs 将小于 4 KiB 的文件放入元数据块中（以避免将数据放置在远离元数据的位置时发生的额外寻道）；这由max_inline安装选项。此外，btrfs 将默认复制元数据，除非mkfs.btrfs在创建文件系统时检测到所选设备是非旋转的；这由--metadata选项总的来说mkfs.btrfs，这意味着每个小于 4 KiB 的文件的磁盘大小至少是其实际数据大小的两倍。
120 万个文件和 18 GB 的数据中，文件的平均大小为 16 KB，我怀疑其中很多文件小于 4 KiB。这可能解释 ext4 上磁盘空间使用量的显著增加。
但是，这种解释令人生疑，因为 ext4（与大多数文件系统一样）在存储小于 4 KiB 的文件时效率也很低，因为它默认的扇区大小为 4 KiB，这意味着每个文件至少占用那么多磁盘空间。Btrfs 在这方面有所不同，因为它将内联数据紧密打包在其元数据块中。我预计，对于小于 2 KiB 的文件，btrfs 的空间效率会比 ext4 更高（在当前默认选项下）。
因此，我认为我在这里的解释是错误的，除非您有很多大小在 2 KiB 到 4 KiB 之间的文件，或者您使用的是 ext4 或 btrfs 的非默认选项。
但如果这个解释是正确的，那么您可以通过不复制元数据来减少 btrfs 中的磁盘空间使用量：只需--metadata single在调用时指定选项mkfs.btrfs（显然，这会减少冗余，因此文件系统对元数据损坏的抵御能力会降低）。对于现有的 btrfs 文件系统，您可以使用以下命令将重复的元数据转换为单个元数据平衡过滤器。
可以使用max_inline=0mount 选项禁用数据内联，但我不建议这样做，因为它会遇到 ext4 和其他文件系统所面临的小文件的空间效率问题。