実際、ここに従来のハードディスクに関するいくつかの質問があります。
ディスク上のすべての読み取り/書き込みは、システム キャッシュ/セクター サイズに合わせて調整されていますか?
ディスク上に作成されたすべてのファイルはセクターに整列されていますか? つまり、ファイルを作成すると、ファイルの開始点はセクターの開始点と同じになりますか?
セクター サイズが 4096 で、位置 10 から 4096 バイトを読み取りたい場合、fseek ( pFile , 10 , SEEK_SET ); 2 回読み取ることになりますか?
詳しい回答をする時間がないので、簡単に説明します。
最新のディスクのディスク セクター サイズは、アプリケーションから見えるよりも低いレベルで動作します。ほとんどの場合、OS でさえ、ディスクによって報告された数値を信頼できません。また、パフォーマンスにはほとんど関係ありません。
従来のファイルシステムを想定すると、重要な調整はディスクのブロックサイズとバッファキャッシュの間です。これは OS/ファイルシステムで発生し、重要な制約は、すべてのアプリケーション レベルの IO-ops がブロックの整数であるということです。これがディスクに持続する間、エクステントとエレベータによって操作が遅延、分割、または順序変更される可能性があることを理解してください。
最新のディスクにはすべてディスク キャッシュがありますが、より高度なディスクはパフォーマンスや信頼性の理由から無効になっている場合があります。繰り返しになりますが、ブロックからセクターに相当するものおよびディスク上のエレベーターへのマッピングは、遅延、分割、マージ、および並べ替えを引き起こす可能性があります。ただし、ほとんどの場合、これについて心配する必要はありません。ディスクが書き込みの現在のステータスについて嘘をついていないことを確認してください。
ほとんどのファイルシステムでは、ファイルはブロックに整列されています。1ブロックが最小読み取りであることを考えると、セクターの配置は問題ではなく、とにかくそれについて何もできません。ファイルシステム/io-subsystem を信頼してこれを適切に行う
ブロックが連続している場合、2 回読み取ることになる可能性はほとんどありません。2 つのブロックを読み取ることになりますが、トラック間のシーク時間が短く、最近の平均的なディスクの順次読み取り速度を考えると、先読みは 1 つのブロック要求に対しておそらく半ダースのブロックを読み取るため、2 番目のブロックは空いています。注: これは、ブロックが連続している場合にのみ適用されます。断片化があると、短いシークまたは長いシークが発生し、何度も実行するとパフォーマンスが低下します。
これが重要な場合は、利用可能なファイルシステムについて時間をかけて学習する必要があります。それらの調整パラメータ; それに応じてデータ構造を計画します。わずかに異なるアプリケーションレベルのブロック/読み取りバッファー/書き込みバッファーサイズで遊ぶことができるように、おそらく構造をパラメーター化する必要もあります。
Just Do Itが機能する最も簡単な方法です。それ以上に複雑にすると、(プログラミング、デバッグ、および保守時間の点で) 多大なコストがかかります。また、これがシステムのボトルネックであることを測定結果が示さない限り、それは無駄な労力です。