このソーススレッドで最も強力な証拠は、600 MB/sのFilesのスクリーンショットではなく、その後に行われたダイレクトストレージテストです。ZimaOSのWebUIコピー速度が約600～650 MB/sにとどまっていたユーザーが、ddで約2.3 GB/sのダイレクト書き込み、fioで約2.2 GB/sの書き込みを測定しました。これは、そのマシンでOS全体の「NVMeがSATA IIIに制限されている」という説明を否定します。
より妥当な結論は、遅い数値は内部Filesコピーのワークフロー、またはメタデータ、BtrfsのCoW、バッファリング、シングルスレッド制限など、コピー処理特有の要因によるものであり、物理的なNVMeパス自体によるものではないということです。
ソースでは複数のコピー経路でこの制限が再現された
Daveは、単一のNVMe間、NVMeからRAID0、RAID0から単一のNVMe、10GbEの各ワークフローで、同様の挙動を報告しました。別のユーザーは後に、WindowsからZimaOSへのSMB転送では10GbEをフル活用できる一方、内部Filesコピーは約650 MB/sにとどまると述べています。
ダイレクトなdd書き込みは約2.3 GB/sに達した
ソースではdd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progressを使用し、SATA IIIの実用スループットを大幅に上回る約2.3 GB/sの結果を掲載しました。
fioでも約2.2 GB/sに達した
ソースのfio実行では、約2163 MiB/s / 2268 MB/sの書き込みが報告されました。選択した同期エンジンによってキュー深度が実質的に1に制限されていたにもかかわらず、この結果は、ストレージスタックがFilesのコピー速度を数倍上回れることを証明しています。
ソースのdd読み込み結果は慎重に扱う
ソースでは、書き込んだばかりのテストファイルを/dev/nullに読み込んだ際、約3.0 GB/sも測定されました。この読み込みではダイレクトI/Oやページキャッシュのフラッシュが明示的に行われていないため、キャッシュが数値に影響している可能性があります。
システム全体のCPU使用率が低くても、シングルスレッドのボトルネックは否定できない
ユーザー空間のコピー処理は、多数のコアを備えたシステムで総CPU使用率が控えめなまま、1つのコアを飽和させることがあります。Filesの低速コピー中は、スレッドごとのCPU使用率とディスク使用率を監視してください。
同じ大容量ファイルをCLIとFilesで比較する
FilesとCLIのコピーで、同じソース、宛先、大容量テストファイルを使用し、その後、使い捨てのダイレクトI/Oベンチマークと比較します。これにより、UIやバックエンドのコピー処理によるオーバーヘッドと、デバイス本来の性能を切り分けられます。
ファイル数とBtrfsのメタデータによって実際のコピー速度は変わる
数千個の小さなファイルではメタデータ操作を繰り返す必要があり、Btrfsのコピーオンライト動作によって内部コピーのコストが変化することがあります。
これを現在のZimaOSにおける普遍的なスロットリングと呼ばない
このソースは、複数のシステムで過去にFilesや内部コピーがボトルネックになっていたことを強く示しています。しかし、現在のZimaOS 1.7.1でも、すべてのハードウェアとファイルシステムの組み合わせでまったく同じ上限が存在することを証明するものではありません。
内部コピーでは、同じストレージに対して同時に読み書きする場合がある
ソースと宛先が同じ物理NVMe、または同じRAIDプール上にある場合、ドライブは読み込みと書き込みを同時に処理する必要があります。そのため、表示されるコピー速度は、一方向のシーケンシャル書き込みベンチマークとは比較できません。
結果を比較する前に、物理的なソースデバイスと宛先デバイスを記録してください。「内部コピー」はソフトウェアの経路を示すものであり、必ずしも2台の独立したSSDを意味するわけではありません。
公称性能を比較する前に、PCIeのリンク幅と世代を確認する
ハイエンドNVMeでも、PCIe x1/x2リンク、古い世代、チップセットのレーン共有、または物理的なコネクターサイズとは異なる配線のプラットフォームスロットによって制限されることがあります。2 GB/sを超える生のベンチマーク結果が得られているなら、600 MB/sの上限は否定できますが、正当なトポロジー上の理由により、デスクトップ向け仕様におけるSSDの最大速度を下回っている可能性はあります。
長時間のコピーでは、SSDの温度やSLCキャッシュの制限が発生することがある
短時間のベンチマークと長時間のファイルコピーでは、SSDへの負荷のかかり方が異なります。ドライブは最初は非常に高速でも、疑似SLCキャッシュがいっぱいになったり温度が上昇したりすると速度が低下する場合があります。低下のすべてをFilesのせいにする前に、十分に長い時間、NVMeの温度と持続的なスループットを監視してください。
ページキャッシュによって、デバイス本来の速度より速く見えるテストがある
ソースのダイレクト書き込み結果は、ダイレクトI/Oを使用しているため、強力な証拠です。一方、書き込み直後に実行した読み込みテストは、ベンチマークが明示的にキャッシュをバイパスしない限り、メモリキャッシュの影響を受ける可能性があります。
再現性のある比較を行うには、ダイレクトI/Oが有効かどうかを明示したベンチマーク設定を使用し、キャッシュによる歪みを抑えるため、テストファイルを十分に大きくしてください。
600 MB/sを固定された製品上限とみなす前に、現在のFilesの処理経路を再テストする
このスレッドは、現在のリリースより前のZimaOSバージョンを対象としています。現在もFilesが上限に達しているように見える場合は、同じ大容量ファイル、同じソースと宛先を使用し、現在のCLIおよびダイレクトI/Oとの比較で再現してください。そうすることで、古い数値上限をいつまでも引き継ぐのではなく、対応に役立つ証拠を得られます。
NVMe速度に関するFAQ
ソースは、ZimaOSがNVMeをSATA速度に制限していることを証明しましたか？
いいえ。同じシステムで、ダイレクトなddおよびfioの書き込みが2 GB/sを超えています。
ソースが最も強く示唆している原因は何ですか？
NVMeデバイス自体ではなく、内部WebUI／ファイルマネージャーのコピー処理経路、またはワークロードによるオーバーヘッドです。
書き込んだばかりのdd読み込み結果は、純粋なディスク速度として扱うべきですか？
必ずしもそうではありません。ダイレクト読み込みやキャッシュ制御がなければ、ページキャッシュが結果に影響する可能性があります。
