我有一個 5 TB 硬碟，其中包含du119k 檔案和目錄中的 3.3 TiB（據報道）媒體檔案；平均檔案大小約為 28 MiB。我使用 .ext4 分割區將其轉換為 btrfs btrfs-convert。該過程耗時 10.4 小時，並且受 CPU 限制。轉換後立即：
# btrfs fi df /mnt/btrfs/
Data, single: total=3.03TiB, used=2.21TiB
System, single: total=32.00MiB, used=236.00KiB
Metadata, single: total=1.52TiB, used=1.10TiB
btrfs 分配了硬碟上的所有空間（3.03 + 1.52 TiB ≈ 5 TB），並且它顯然將約 1 TiB 的檔案內容放入元資料區塊中（使用了 1.10 TiB）。這是出乎意料的，因為我的文件很少適合葉節點。
巨大元資料分配的標準解決方案是重新平衡元資料。btrfs balance start -m花了 8.0 小時並且受 I/O 限制。之後看來，btrfs 不僅釋放了未使用的元資料塊，還將檔案內容從元資料塊移動到資料塊中。
# btrfs fi df /mnt/btrfs/
Data, single: total=3.32TiB, used=3.31TiB
System, single: total=32.00MiB, used=104.00KiB
Metadata, single: total=3.00GiB, used=2.18GiB
有人可以解釋發生了什麼事嗎？為什麼「元資料」最初會消耗 1.10 TiB，為什麼平衡會將其減少到 2.18 GiB？是否btrfs balance將文件內容從元資料塊移動到資料塊？
我使用Linux核心3.13.0-46。我的文件沒有硬連結、xattrs、SELinux 上下文或 ACL。我沒有打開壓縮，也沒有刪除ext4回滾鏡像。
答案1
首先，轉換過程會將所有先前系統元資料的副本保存在新元資料中，這可能會佔用大型磁碟機上的大量空間。
其次，轉換過程很混亂，導致盤區非常大，因為 EXT4 中的盤區也很大，而 BTRFS 將固有其大小。
分配的大小大約為所使用元資料大小的 1.5 倍。碎片整理過程將減少所使用的元資料的大小，但不會更改分配。還有一個瘦範圍選項可以進一步減少元數據，但這對於具有大量小檔案的系統更有幫助；您的元資料分配不到百分之十分之一，這是非常小的。
平衡命令應該根據當前元資料使用情況將分配大小減少到新值，這似乎做得正確。平衡命令不應該從元數據移動到數據，但這可能與原始元數據分配中的原始 EXT4 元數據映像副本有關，現在已移動到數據（ext2_saved 子卷）中。檢查EXT4鏡像的大小是否為1.1TB。無論如何，我都會對檔案系統進行碎片整理。
應該注意的是，在沒有碎片整理的情況下運行平衡可能會導致錯誤。建議使用較新版本的核心來防止檔案系統問題，特別是 3.17 及更高版本。