ZimaOS Files で約 600～650 MB/s と表示されても、NVMe デバイス自体が SATA 速度に制限されていることの証明にはなりません。ソースのコミュニティガイドは、raw ストレージスループットとファイルコピーのワークフロースループットを正しく区別しています。ブラウザベースのファイルマネージャーでは、ダイレクトベンチマークでは測定されないメタデータ処理、進捗追跡、安全対策、ユーザー空間でのコピー、ファイルシステムのオーバーヘッド、ファイルごとの処理が追加されることがあります。
最も有用な方法は比較です。まず、大きなシーケンシャルなダイレクト I/O ワークロードで同じストレージをテストし、次に同じ大きなファイルを CLI と Files でコピーします。raw/direct テストが複数 GB/s である一方、GUI のコピーが 600 MB/s 前後にとどまるなら、ボトルネックはおそらく NVMe デバイスより上位の層にあります。
1つのファイルコピーの数値は NVMe ベンチマークではありません
内部コピー速度は、次の要因に左右されます。
- コピー元とコピー先が同じデバイスか異なるデバイスか；
- ファイルシステムの種類；
- コピーオンライトの動作；
- ファイルサイズとファイル数；
- CPU オーバーヘッド；
- ページキャッシュ；
- コピーの実装。
600 MB/s の結果は、あるワークフローでは優秀でも、別のワークフローでは低い可能性があります。
大きなシーケンシャルテストファイルから始める
大きなファイルを使用すると、メタデータの影響が小さくなり、持続的なスループットを解釈しやすくなります。ソースでは、ワークロードが観測に十分な時間実行されるよう、10 GB のファイルを使用していました。
大きなテストファイルを作成する前に、対象ストレージに十分な空き容量があることを確認してください。システムディスクやデータディスクを満杯にするベンチマークは、別の障害を引き起こす可能性があります。
ソースでは dd をダイレクト書き込みで使用していました
コミュニティガイドでは、次のように提案されていました。
dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progressoflag=direct 書き込み処理におけるページキャッシュの影響を軽減します。これは、大まかなシーケンシャル書き込みチェックに役立ちます。
すべてのビルド、デバイス、ファイルシステムが、同じブロックサイズやダイレクト I/O の動作を同じように受け入れるとは限りません。
ソースの dd 読み取りテストの解釈には、より注意が必要です
その後、ソースではファイルを読み取り、 /dev/nullダイレクト I/O の読み取りオプションやキャッシュ制御がない場合、最近使用したファイルの一部がページキャッシュから提供され、見かけ上の読み取り速度が誇張される可能性があります。
信頼性の高いストレージ比較には、両方向でダイレクト I/O を明示的に使用するツールまたは設定を優先するか、キャッシュの影響を把握しておいてください。
fio は、より適切に制御できるストレージベンチマークです
ソースで使用されていた持続書き込みの例は次のとおりです。
fio --name=nvme --filename=/DATA/fio.test --size=10G --rw=write --bs=1M --iodepth=32 --numjobs=1 --direct=1 --runtime=30 --group_reportingこれは依然としてコミュニティによるガイダンスですが、テストサイズ、シーケンシャル書き込み、キュー深度、ダイレクト I/O、実行時間、グループ化された結果が明示されており、ベンチマークとしてより明確な形になっています。
実データを含む raw デバイスに、破壊的な fio ジョブを決して実行しないでください。結果を十分に理解している場合を除き、ファイルシステム上の使い捨てテストファイルを使用してください。
同じデータセットでGUIとCLIを比較
ソースで最も強く推奨されている方法は、両方に同じ大容量ファイルを使用することです。
- CLIでのコピー。
- ZimaOS Filesでのコピー。
データセット、送信元、送信先、ファイルシステムが同一なら、その差はコピー処理の違いをより直接的に反映します。
小さなファイルでは大幅に遅くなることがある
数千枚の写真、プロジェクトファイル、サムネイル、AppDataのエントリでは、open／create／メタデータ／チェックサム処理を繰り返し行う必要があります。そのため、非常に高速なNVMeでも、合計転送速度は単一の大容量動画やISOを転送する場合より大幅に低下することがあります。
Btrfsのコピーオンライトとメタデータ処理により、正確な操作内容によってはさらにオーバーヘッドが加わることがあります。
遅いコピーの実行中にCPUとI/Oを監視する
ソースでは、ディスク使用率とCPUを同時に監視することを推奨しています。目的は、次のどれに該当するかを特定することです。
- ディスクが飽和している。
- CPUの1コアがボトルネックになっている。
- 別のプロセスがI/Oを奪い合っている。
- コピー処理がストレージを駆動せず、待機している。
Filesの進捗バーの数値だけを示すよりも、こちらのほうが有益です。
NVMeの速度はPCIeレーンとデバイスにも左右される
正常なNVMeでも、次の場合は公称値を下回ることがあります。
- スロットがPCIe x4ではなくx1／x2である。
- プラットフォームがPCIe Gen 4ではなくGen 3である。
- SSDが熱によるスロットリングを起こしている。
- コントローラーがレーンを共有している。
- 持続的な書き込み中にSLCキャッシュが使い果たされている。
実際のベンチマークは、「NVMe＝7 GB/s」という一般的な期待値ではなく、ハードウェア構成と比較すべきです。
現在のIceWhale転送ガイドでもUIと高速な転送経路を分けて説明
IceWhaleのZimaCube Thunderboltガイドでは、ZimaOSのUI転送経路は直接的なSamba／Thunderbolt経路よりも遅いことが従来から示されており、ファイルUIが生のネットワーク／ストレージスループットと同一ではないという一般的な点を裏付けています。
サポートされているネットワーク側の確認には、現在のZimaOS転送トラブルシューティングチェックリストを使用してください。
完了後にテストファイルを削除
大容量 dd/fio ファイルはすぐに数十ギガバイトの容量を消費することがあります。結果を記録したら、既知のテストファイルを削除し、その後に空き容量を確認してください。
NVMeベンチマークに関するよくある質問
ZimaOS Filesで600 MB/sと表示されたら、NVMeがSATA速度に制限されている証拠になりますか？
いいえ。それはコピー処理のワークフローを測定するものであり、NVMeの生の性能を測定するものではありません。
ddの読み取りが現実離れして速く見えるのはなぜですか？
最近書き込まれたファイルは、読み取りテストでキャッシュを明示的に回避しない限り、一部がページキャッシュから提供される可能性があります。
GUIコピー処理を比較する最適な方法は何ですか？
CLIとFilesの両方で同じ送信元／送信先と同じ大容量データセットを使用し、CPUとストレージI/Oを監視しながら比較します。
