ファイルが「ブロック」サイズの倍数でディスクに保存されることは、十分に確立された事実です。
ブロックの概念は、ディスク上の物理セクターをファイルシステムで論理的に表現する簡単な方法として始まりました。各セクターには独自のヘッダー、データ領域、およびECCがあり、論理的に独立して表現できる最小のディスクでした。
時が経つにつれて、HDD コントローラーにキャッシュが出現したことで、複数の物理セクターのサイズの論理ブロックを持つことが容易になりました。このようにして、ディスク上のシーケンシャル I/O が増加し、スループットが向上しました。
現在、ブロックは利用可能なディスク領域の最小単位です。通常、ファイルはディスク上の 1 つ以上のブロックを使用して保存されます。
各ファイルでは、ファイルに変更が加えられるたびに最後のブロックに残っているスペース (存在する場合) が使用され、ファイルが「大きくなる」ため、新しく追加されたコンテンツを格納するために追加のディスク スペースが必要になります。
追加の領域要件 (現在の最後のブロックの空き領域が収容できる容量を超える) は、ディスク上の追加のブロックを要求し、新しいブロック セットを論理的にリンクして、ファイルの現在の最後のブロックに続くようにすることで満たされます。ファイル Aは、上記のシナリオを示しています。
事前にブロックを割り当てる利点は、断片化が減少することです。ディスク上のブロックの概念がなく、必要に応じてディスク領域が割り当てられる代替案を検討してください。つまり、割り当てられたディスク領域の量はファイル サイズとまったく同じです。
このようなセットアップでは、1 文字でもファイルに追加されるたびに、次の操作が必要になります。
- 追加のメモリを割り当てます (さらに 1 文字)。
- ファイルの初期領域を含む領域とこの新しいバイトの間にリンクを設定します。
このすべてのメタデータ、つまり「リンク」に関する追加の構成には、ディスク容量も必要です。これは、そのような「リンク」ごとに固定のオーバーヘッドを構成するため、そのような「リンク」を最小限の数に保つことが不可欠です。ディスク サイズを「ブロック」に割り当てるという概念により、オーバーヘッドが事前に決定された量に制限されます。
ディスク上の保証ファイル数 = Raw ディスク容量 / ブロックサイズ
また、ディスク I/O で最も時間のかかるタスクはディスク ヘッドの再配置であるため、このようなランダム シークはスループットを低下させます。頻繁なランダム シークも、ディスクの消耗を早める可能性が高く (ダンシング HDD を覚えていますか?)、可能な限り回避する必要があります。
このアプローチのその他の利点:
1.読み取りの高速化
ブロックを使用すると、ディスクの読み取りはブロック サイズまでシーケンシャルに行われます。シークが少ない = 読み取りスループットが高い。
2.書き込みの高速化
ブロックは、ページにマップできる単純な実装を提供するため、書き込みスループットも向上します。