私は 5 TB のハード ドライブを持っており、3.3 TiB ( による報告du) のメディア ファイルが 119k のファイルとディレクトリに格納されています。平均ファイル サイズは約 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 使用)。リーフ ノードに収まるファイルはほとんどないため、これは予想外です。
膨大なメタデータ割り当てに対する標準的な解決策は、メタデータのバランスを再調整することです。8.0btrfs balance start -m時間かかり、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 を使用しました。ファイルにはハード リンク、xattr、SELinux コンテキスト、ACL はありません。圧縮はオンにしておらず、ext4 ロールバック イメージも削除していません。
答え1
まず、変換プロセスでは、以前のすべてのシステム メタデータのコピーが新しいメタデータに保存されますが、大容量ドライブではかなりの容量を占有する可能性があります。
2 番目に、変換プロセスが煩雑になり、EXT4 のエクステントも大きく、BTRFS がそのサイズを継承するため、エクステントが非常に大きくなります。
割り当てられるサイズは、使用されるメタデータ サイズの約 1.5 倍になります。デフラグ処理によって、使用されるメタデータのサイズは削減されますが、割り当ては変更されません。メタデータをさらに削減するスキニー エクステント オプションもありますが、これは大量の小さなファイルがあるシステムでより役立ちます。メタデータの割り当ては 10 分の 1 パーセント未満で、非常に小さいです。
バランス コマンドは、現在のメタデータの使用状況に基づいて割り当てサイズを新しい値に減らすはずであり、正しく実行されたようです。バランス コマンドはメタデータからデータに移動することになっていませんが、元の EXT4 メタデータ イメージ コピーが元のメタデータ割り当てにあり、現在はデータ (ext2_saved サブボリューム) に移動されていることと関係がある可能性があります。EXT4 イメージのサイズが 1.1 TB かどうかを確認してください。いずれにしても、ファイル システムをデフラグします。
デフラグせずにバランスを実行するとエラーが発生する可能性があることに注意してください。ファイルシステムの問題を防ぐために、カーネルの新しいバージョン、具体的には 3.17 以降が推奨されます。