私の質問は、NTFS Fs でのファイル割り当て方法についてです。
主な質問が 2 つあります -
小さなアプリケーション用に単純なファイル ベースの DB を作成しようとしていますが、ファイル内に自分のデータベースを作成したいと考えています。パフォーマンス上の理由から、データをディスク上で連続した順序で保持し、まとめて読み取る必要があります。(アプリケーションでこのファイルを mmap する予定です)。
このスーパーユーザーの回答によると、システムにファイル サイズのヒントを提供するために呼び出すSetEndOfFileことができます。これにより、NTFS はファイル全体に連続したストレージを割り当てることができます。
マルチタスクまたはマルチユーザー オペレーティング システムのもう 1 つの重要なポイントは、ファイルが連続して格納されている場合でも、ファイル アクセスの途中で別のタスクがドライブを呼び出して読み取りまたは書き込みを行う可能性があることです。これにより、ドライブは完全に別の場所を探します。ビジー状態のシステムでは、これが常に発生している可能性があります。
オペレーティング システム ドライバーは、データがディスクに表示される順序で、さまざまなタスクのバッファーへの読み取りまたはバッファーからの読み取りまたは書き込みをスケジュールしようとする、スキャッター ギャザーまたはエレベーター アルゴリズムなどのアルゴリズムを使用できるため、ヘッドは内側から順番にスイープできます。外側のトラック、またはその逆で、途中でデータを取得または削除します。
エレベーター アルゴリズムは、実際のエレベーターがさまざまなフロアの乗客からの要求に基づいて、最も効率的な積み下ろしパターンを選択する必要があるため、そのように名付けられました。彼らは、時間とエネルギーを非効率的に上下に浪費する余裕はありません。ディスク ドライブのヘッドの位置はそれほど変わりません。
では、ポイントごとにお答えしましょう...
質問 1 : NTFS でファイルを作成すると、物理ハード ディスクに連続して保存されますか?
質問は意味がありません。ファイルを作成すると、NTFS は、追跡に必要なメタデータ用に MFT にスペースを割り当てます。小さなファイルは、実際にはファイルの MFT レコード内に収まる場合があります。そのような常駐ファイルは、定義上、連続しています。ファイルが MFT 内に収まらない場合は、必要に応じて領域のブロックが割り当てられ、連続している場合と連続していない場合があります。一般的に言えば、ファイルの大きさや事前に割り当てる容量がわからないため、NTFS は必要に応じて容量を割り当てますが、SetEndOfFile関数を呼び出すことでヒントを与えることができます。しかし、それはヒントを提供するだけであり、保証はありませんファイル データがディスクの連続した領域に格納されるようにします。実際、たとえファイルシステムがリアルタイムで最適化を実行したとしても、空き領域が単一の連続したディスク アドレスのブロックとして利用可能であることを *保証できないことを自分自身に納得させるのは簡単なことです。
質問 2 :そうでない場合 - ファイルに書き込むときに、データが連続して (ハードディスクに) 格納されるようにファイルを作成する方法はありますか? データベースのエクステントのようなもの。
なぜこれが重要な懸念事項だと思いますか。通常、ファイルシステムがデータをどのように格納するかは気にする必要はありません。データを保存するという事実だけを気にする必要があります。継続的に保存されていないファイルへのアクセスは遅くなると思うかもしれませんが、必ずしもそうとは限りません。高度なキャッシュ アルゴリズムと O/S によるプリフェッチにより、速度低下が完全に解消されることがよくあります。懸念事項がパフォーマンスである場合、ファイルシステムによる断片化が問題であることを示す実際のハードデータはありますか? その場合、正しいアプローチは、別のファイルシステムを使用するか、ファイルシステムをまったく使用しないことです。
質問 3 :そのようなファイルが存在する場合 - そのファイルから (C read システム コールを使用して) 束/ブロックでデータを読み取る方法はありますか。使用できる最大束サイズは?
C システム コール ( などfread) は、NTFS、断片化、「束」、およびブロックについて認識しません。彼らが知っているのは、指定されたファイルハンドルから要求されたバイト数を読み取る方法と、指定したバッファにデータを入れる方法だけです。実際には任意のサイズを指定できますが、C ライブラリは O/S およびファイルシステム固有の API を呼び出して、ブロック サイズの倍数でデータを読み取りますが、これは実装定義です。
それは可能性があります。ただし、物理ハード ディスクに連続して格納されることは保証できません。
ハードディスクへの低レベルの raw アクセスを使用して、これを行うことができます。一部の大きなデータベース システムでは、ファイル システムを使用せず、ハードディスクに直接書き込み/読み取りを行います。また、ハードディスク内のデータ構成は、データベース システムによって定義されます。
ファイルが物理的にどのように保存されていても、C でブロック単位で読み取ることができます。「最大束サイズ」はないと思います。しかし、(ファイルシステムのブロックサイズ) * N のように、「適切な束サイズ」が存在します。
ファイルシステム reiserfs は、大量の小さなファイルを保存するのに適していると言われています。しかし、私はそれをテストしたことはありません。