単一ディスク上の最速のLinuxファイルシステム

瓦屋根のドライブには大きな関心が寄せられています。これらはデータトラックを非常に近づけるため、次のトラックを上書きせずに1つのトラックに書き込むことはできません。これにより容量が20％程度増加する場合がありますが、書き込み増幅の問題が発生します。Shingledドライブ用に最適化されたファイルシステムで進行中の作業があります。たとえば、https：//lwn.net/Articles/591782/を参照してください。

Seagate 8TBアーカイブなどの一部のシングルディスクには、ランダム書き込み用のキャッシュ領域があり、汎用ファイルシステムで適切なパフォーマンスを実現できます。いくつかの一般的なワークロードでは、ディスクは非常に高速で、最大で毎秒200MBの書き込みが可能です。ただし、ランダム書き込みキャッシュがオーバーフローすると、パフォーマンスが低下することが予想されます。おそらく、いくつかのファイルシステムは、一般的なランダム書き込み、またはそのようなドライブで見つかった書き込みキャッシュをオーバーフローさせる可能性があるランダム書き込みのパターンを回避するのに優れています。

Linuxカーネルのメインストリームファイルシステムは、ext4よりもシングルディスクのパフォーマンスの低下を回避するのに優れていますか？

直観的なコピーオンライトおよびログ構造化ファイルシステムは、ランダム書き込みを減らすことにより、シングルディスクのパフォーマンスを向上させる可能性があります。ベンチマークはこれをある程度サポートしますが、これらのパフォーマンスの違いは、シングルディスクに固有のものではありません。それらは、コントロールとして使用される単一化されていないディスクでも発生します。したがって、シングルディスクへの切り替えは、ファイルシステムの選択とはあまり関係がありません。

nilfs2ファイルシステムは、SMRディスク上で非常に優れたパフォーマンスを発揮しました。ただし、これは8TBパーティション全体を割り当てたためであり、ベンチマークでは0.5TBしか書き込まれていないため、nilfsクリーナーを実行する必要はありませんでした。パーティションを200GBに制限すると、nilfsベンチマークは正常に完了しませんでした。Nilfs2は、すべてのデータとスナップショットを永久にディスクに書き込むアーカイブディスクとして「アーカイブ」ディスクを実際に使用する場合、nilfsクリーナーを実行する必要がないため、パフォーマンス面で適切な選択です。

私は8TBのSeagateのことを理解しST8000AS0002-1NA17Z、私はテストのために使用されているドライブを持っている〜20ギガバイトのキャッシュ領域を。デフォルトのfilebenchファイルサーバー設定を変更して、ベンチマークセットが〜125GBになり、単一化されていないキャッシュ領域より大きくなるようにしました。

set $meanfilesize=1310720
set $nfiles=100000
run 36000

次に、実際のデータについて説明します。opsの数は「全体的な」ファイルサーバーのパフォーマンスを測定し、ms / opはランダム追加のレイテンシを測定し、ランダム書き込みのパフォーマンスの大まかなガイドとして使用できます。

$ grep rand *0.out | sed s/.0.out:/\ / |sed 's/ - /-/g' |  column -t
SMR8TB.nilfs   appendfilerand1   292176ops 8ops/s   0.1mb/s   1575.7ms/op    95884us/op-cpu [0ms - 7169ms]
SMR.btrfs      appendfilerand1  214418ops  6ops/s   0.0mb/s  1780.7ms/op  47361us/op-cpu  [0ms-20242ms]
SMR.ext4       appendfilerand1  172668ops  5ops/s   0.0mb/s  1328.6ms/op  25836us/op-cpu  [0ms-31373ms]
SMR.xfs        appendfilerand1  149254ops  4ops/s   0.0mb/s  669.9ms/op   19367us/op-cpu  [0ms-19994ms]
Toshiba.btrfs  appendfilerand1  634755ops  18ops/s  0.1mb/s  652.5ms/op   62758us/op-cpu  [0ms-5219ms]
Toshiba.ext4   appendfilerand1  466044ops  13ops/s  0.1mb/s  270.6ms/op   23689us/op-cpu  [0ms-4239ms]
Toshiba.xfs    appendfilerand1  368670ops  10ops/s  0.1mb/s  195.6ms/op   19084us/op-cpu  [0ms-2994ms]

Seagateは5980RPMであるため、東芝は20％高速になると単純に予想できます。これらのベンチマークでは、約3倍（200％）高速であることが示されているため、これらのベンチマークはパフォーマンスのペナルティを大幅に下回っています。Shingled（SMR）ディスクは、unshingled（PMR）ディスクのパフォーマンスext4とまだ一致しないことがわかります。最高のパフォーマンスは、8TBパーティションのnilfs2を使用することでした（したがって、クリーナーは実行する必要がありませんでした）が、それでもext4を使用する東芝よりも大幅に低速でした。

上記のベンチマークをより明確にするために、各ディスク上のext4のパフォーマンスに関連してベンチマークを正規化すると役立つ場合があります。

                ops     randappend
SMR.btrfs:      1.24    0.74
SMR.ext4:       1       1
SMR.xfs:        0.86    1.98
Toshiba.btrfs:  1.36    0.41
Toshiba.ext4:   1       1
Toshiba.xfs:    0.79    1.38

SMRディスクでは、btrfsがext4での全体的な操作に対してほとんどの利点を持っていますが、ランダムアペンドに対するペナルティは比率ほど劇的ではありません。これにより、SMRディスク上のbtrfsに移動する可能性があります。一方、低レイテンシのランダムアペンドが必要な場合、このベンチマークは、特にSMRでxfsが必要であることを示唆しています。SMR / PMRがファイルシステムの選択に影響を与える可能性がありますが、最適化するワークロードを考慮することはより重要であると思われます。

また、屋根裏ベースのベンチマークを実行しました。屋根裏部屋の実行時間（8TB SMRフルディスクパーティション上）は次のとおりです。

ext4:  1 days 1 hours 19 minutes 54.69 seconds
btrfs: 1 days 40 minutes 8.93 seconds
nilfs: 22 hours 12 minutes 26.89 seconds

それぞれの場合、屋根裏リポジトリには次の統計がありました。

                       Original size      Compressed size    Deduplicated size
This archive:                1.00 TB            639.69 GB            515.84 GB
All archives:              901.92 GB            639.69 GB            515.84 GB

同じ1 TBディスクの2番目のコピーを屋根裏部屋に追加するには、これら3つのファイルシステムのそれぞれで4.5時間かかりました。ベンチマークとsmartctl情報の生のダンプは、http ： //pastebin.com/tYK2Uj76 https://github.com/gmatht/joshell/tree/master/benchmarks/SMRにあります。

SMRドライブを使用rsync している場合は、ファイルシステムがマウントされているread-onlyか、noatimeオプションが指定されていることを確認してください。

そうしないと、SMRドライブは各ファイルのrsync読み取りのタイムスタンプを書き込む必要があり、その結果、パフォーマンスが大幅に低下し（ここでは約80 mb / sから3-5 mb / sに低下）、ヘッドウェア/クリック音が発生します。

パフォーマンスの低いrsyncジョブを既に実行している場合は、停止する必要はありません。ソースファイルシステムを再マウントして実行できます

sudo mount -o remount,ro  /path/to/source/fs

ドライブがバッファ内にあるすべてのデータの書き込みを完了するまで、効果はすぐには見られず、辛抱強く10〜20分待ちます。このアドバイスは試され、問題なくテストされています。

これは、SMRドライブへのrsyncing 時、つまりファイルがディスクに完全に書き込まれた後にファイルシステムがタイムスタンプを更新しようとした場合にも当てはまる場合があります。これによりシーケンシャルワークロードが揺らぎ、膨大なデータのバンドが継続的に書き換えられ、ドライブの摩耗に寄与します。以下が役立つ場合があります。

sudo mount -t fs_type -o rw,noatime device /path/to/dest/fs

これは、rsyncを実行する前に行う必要があります。他の要因により、このオプションが重要でなくなる可能性があります。つまり、バッファなしのFAT / MFT更新、ファイルシステムが主にSSD向けに最適化されている場合の並列書き込みなどです。

dd bs=32Mとにかく完全なファイルシステムをバックアップする場合は、SMRターゲットのファイルシステムを使用してからサイズを変更してください（この場合、すべてのファイルを転送するためにマウントしてrsyncを実行する必要はありません）。

実際に使用されているハードウェアは、Seagateドライブで管理されるSMR 8tbコンシューマードライブです。走行距離は他のハードウェアによって異なる場合があります。