メールのバックアップ ファイル (offlineimap から) がいっぱい入ったフォルダーがあります。そのようなフォルダーの 1 つには 87k のファイルがあり、そのうち 68k は 512 ～ 1024 バイトのサイズです (この 1 つのフォルダーは、残りのフォルダーのかなり代表的なものです)。全体のサイズ分布は次のようになります。
Size bin % by count % by space
512 0.08% 0.00%
1024 77.37% 74.58%
2048 1.65% 1.62%
4096 3.92% 4.05%
8192 6.11% 6.78%
16384 3.68% 4.25%
32768 3.07% 3.66%
65536 1.77% 2.15%
131072 0.75% 0.92%
262144 0.36% 0.44%
524288 0.33% 0.41%
1048576 0.30% 0.37%
2097152 0.21% 0.27%
4194304 0.20% 0.25%
8388608 0.11% 0.14%
16777216 0.08% 0.10%
私の質問は、このデータに使用する最適なレコード サイズはどれかということです。1k と考えがちですが、これは通常の推奨値よりもはるかに小さいため、メタデータによるオーバーヘッドが懸念されます。
これについて触れた記事をいくつか読んだが、結論には至らなかった。例えば、1つの記事平均ファイルよりも小さいレコード サイズを使用した場合のストレージ効率を調べます。平均最小ファイル サイズは 128k で、圧縮によりブロック サイズが 512k から 128k に増加するにつれてストレージ効率が向上することがわかりましたが、ファイルよりも大きいブロック サイズはテストしていないため、全体的な傾向は明らかではありません。
もう一つのよい読み物はこのRedditのスレッドレコード サイズとブロック サイズの違いについて説明し、SSD パフォーマンスのチューニングについて説明します。
答え1
結局、@ewwhite の言うとおりにして、簡単なベンチマークを実行しました。結論としては、128k で十分です。
BlockSize CompRatio du-s
1 0 50747244
2 1 26001757
4 1 13487472
8 1.04 12690656
16 1.06 9560063
32 1.08 8011524
64 1.09 7872713
128 1.1 7822344
256 1.11 7804225
512 1.14 7799985
1024 1.16 7801688
答え2
ZFS プールのレコード サイズを変更することはほとんどありません。デフォルトの 128K は、ほとんどのワークロードに適しています。
さまざまなレコード サイズで簡単にベンチマークできます...
ストレージのパフォーマンスが懸念事項である場合は、他の場所で最適化する機会がさらにあります。OS/ハードウェア/要件に関する詳細はありますか?