Loading article…
コンピューティングにおいて、ファイル システムの断片化(ファイル システムのエージングとも呼ばれる) とは、ファイル システムがファイルの内容を非連続的にレイアウトして、その内容のインプレース変更を可能にする傾向のことです。これは、データの断片化の特殊なケースです。ファイル システムの断片化は、回転するストレージ メディアのシーク時間に悪影響を及ぼし、スループットを低下させることが知られています。断片化は、ファイルと空き領域を連続した領域に再編成することで解決できます。このプロセスはデフラグと呼ばれます。
ソリッドステートドライブは物理的にシークしないため、非シーケンシャルデータアクセスは移動ドライブよりも数百倍高速で、断片化の問題が少なくなります。ソリッドステートストレージを手動でデフラグすることはお勧めしません。不要な書き込み消去操作によってドライブが早期に摩耗する可能性があるためです。[1]
原因
ファイルシステムがパーティション上で最初に初期化されるとき、そこにはいくつかの小さな内部構造しか含まれておらず、それ以外は 1 つの連続した空き領域のブロックです。[a]つまり、ファイルシステムは新しく作成されたファイルをパーティション上の任意の場所に配置できます。作成後しばらくの間は、ファイルはほぼ最適にレイアウトされます。オペレーティングシステムとアプリケーションがインストールされるか、アーカイブが解凍されると、個別のファイルが順番に発生するため、関連するファイルは互いに近くに配置されます。
既存のファイルが削除または切り捨てられると、新しい空き領域が作成されます。既存のファイルに追加されると、別のファイルがすでにそこに割り当てられている可能性があるため、ファイルが終了していた場所から書き込みを再開することが不可能になることがよくあります。そのため、新しいフラグメントを割り当てる必要があります。時間が経つにつれて、同じ要因が継続的に存在するため、空き領域と頻繁に追加されるファイルは、さらに断片化する傾向があります。空き領域が短くなると、ファイル システムは新しいファイルを連続的に割り当てることができなくなり、それらをフラグメントに分割する必要があります。これは、ファイル システムがいっぱいになり、大きな連続した空き領域が使用できなくなる場合に特に当てはまります。
例
次の例は、複雑な主題を簡略化したものです。次のシナリオを考えてみましょう。新しいディスクに、A、B、C、D、E という 5 つのファイルが、この順序で連続して保存されています。各ファイルは 10ブロックの領域を使用しています (ここでは、ブロック サイズは重要ではありません)。ディスク領域の残りは 1 つの空きブロックです。したがって、ファイル E の後に、追加のファイルを作成して保存できます。
ファイル B が削除されると、10 ブロックの空き領域からなる 2 番目の領域が作成され、ディスクが断片化されます。空き領域はそのまま残され、後で使用できるようにマークされ、必要に応じて再度使用されます。[b]ファイル システムは、削除後すぐにディスクをデフラグすることもできますが、これを行うと、予期しないタイミングでパフォーマンスが大幅に低下します。
ここで、7 ブロックのスペースを必要とする F という新しいファイルを、以前ファイル B が置かれていた新しく解放されたスペースの最初の 7 ブロックに配置することができ、それに続く 3 つのブロックは使用可能なままになります。3 つのブロックのみを必要とする G という別の新しいファイルを追加すると、F の後、C の前のスペースを占有できます。
その後 F を拡張する必要がある場合、その直後のスペースが占有されているため、ファイル システムには 3 つのオプションがあります。
- 別の場所に新しいブロックを追加し、Fに2番目の範囲があることを示す
- Fが連続した状態を保つために、拡張の途中でファイルを他の場所に移動します。
- ファイルFを移動して、新しい、より大きなサイズの連続した1つのファイルになるようにします。
2 番目のオプションは、パフォーマンス上の理由からおそらく非現実的であり、ファイルが非常に大きい場合の 3 番目のオプションも同様です。3 番目のオプションは、新しいファイルを格納するのに十分な大きさの連続した空き領域が 1 つもない場合は不可能です。したがって、通常は、別の場所にエクステントを作成し、新しいエクステントを古いエクステントに連結するだけです。
ファイル F の末尾に追加された素材は、同じエクステントの一部になります。ただし、素材が多すぎて最後のエクステントの後に空き領域がない場合は、別のエクステントを作成する必要があります。最終的には、ファイル システムの多くの場所に空きセグメントが存在し、一部のファイルは複数のエクステントに分散される可能性があります。これらのファイル (またはすべてのファイル) のアクセス時間は非常に長くなる可能性があります。
必要性
初期のファイルシステムの中には、ファイルを断片化できないものもありました。その一例が、BBC Microで使用されていたAcorn DFSファイルシステムです。ファイルを断片化できないため、拡張できないというエラーメッセージが表示されることがあり、ディスクに十分な空き容量があっても、ユーザーはファイルを保存できないことがよくありました。
DFS は非常に単純なディスク構造を使用しており、ディスク上のファイルは長さと開始セクターによってのみ検索されます。つまり、すべてのファイルは連続したセクター ブロックとして存在する必要があり、断片化は不可能です。上記の表の例を使用すると、ステップ 5 でファイル F を拡張しようとすると、このようなシステムでは拡張できないというエラー メッセージが表示されて失敗します。ディスクに合計でどれだけの空き領域が残っていたとしても、データ ファイルを拡張することはできません。
当時のエラー処理の標準は原始的であり、いずれにしても BBC Micro の限られたメモリに詰め込まれたプログラムでは、エラーを適切に処理しようとしてスペースを無駄にする余裕はほとんどありませんでした。代わりに、ユーザーはコマンド プロンプトでCan't extend というメッセージが表示され、ファイルにまだ追加されていないすべてのデータが失われることに気付きました。この問題は、単にディスクの空き容量を事前にチェックするだけでは解決できませんでした。ディスクに空き容量が存在する場合でも、ディスク カタログによって提示される数値を分析しなければ、空き容量の最大の連続ブロックのサイズはすぐにはわかりません。そのため、ユーザーは気付かないでしょう。さらに、ほとんどすべての DFS ユーザーは、このエラーが発生しないカセット ファイル ストレージを以前に使用していました。フロッピー ディスクシステムへのアップグレードは高価なアップグレードであり、アップグレードによって警告なしにデータが失われる可能性があることはショックでした。[2] [3]
種類
ファイル システムの断片化は、いくつかのレベルで発生する可能性があります。
ファイルの断片化
個々のファイルの断片化は、1 つのファイルが複数の断片 (エクステント ベースのファイル システムではエクステントと呼ばれる) に分割されたときに発生します。ディスク ファイル システムは個々のファイルを連続的に維持しようとしますが、パフォーマンスに重大なペナルティを課さずにこれが可能であることはめったにありません。ファイル システム チェックおよびデフラグ ツールは通常、ファイルの断片化を「断片化率」統計でのみ考慮します。
空き領域の断片化
空き (未割り当て) 領域の断片化は、ファイル システムに新しいファイルやメタデータを書き込むことができる未使用の領域が複数ある場合に発生します。不要な空き領域の断片化は、通常、ファイルの削除または切り捨てによって発生しますが、ファイル システムでは、近くのファイルを拡張しやすくするために、空き領域の断片 (「バブル」) を意図的に挿入することもあります (以下の断片化の防止を参照してください)。
ファイルの分散
ファイルセグメンテーションは、関連ファイルの断片化、またはアプリケーションレベル（ファイル）の断片化とも呼ばれ、関連ファイル間の参照の局所性（保存媒体内）の欠如を指します。前の 2 種類の断片化とは異なり、ファイルの分散は、特定のアプリケーションのアクセス パターンに大きく依存するため、はるかに曖昧な概念です。これにより、客観的に測定または推定することも非常に困難になります。ただし、最も頻繁にアクセスされるファイルは、1 秒あたりの利用可能なディスク スループットに比べて小さい傾向があることが研究で判明しているため、これは間違いなく最も重要な種類の断片化です。[4]
関連ファイルの断片化を回避し、参照の局所性 (この場合はファイルの連続性と呼ばれます) を改善するには、アプリケーションの操作に関する仮定または積極的な観察を行う必要があります。非常によく行われる仮定は、小さなファイルを 1 つのディレクトリ内にまとめて保存し、自然なファイル システムの順序で配置する価値があるというものです。これは多くの場合妥当な仮定ですが、常に当てはまるとは限りません。たとえば、アプリケーションは、おそらく異なるディレクトリにある複数の異なるファイルを、書き込まれた順序とまったく同じ順序で読み取る場合があります。したがって、すべての書き込みを単純に順番に順序付けるファイル システムは、特定のアプリケーションではより高速に動作する可能性があります。
データ構造の断片化
ファイルシステム自体が使用するカタログやインデックスも、含まれるエントリが作成、変更、または削除されるにつれて、時間の経過とともに断片化される可能性があります。これは、ボリュームが少数の大きなファイルで満たされている場合よりも、ボリュームに多数の非常に小さなファイルが含まれている場合に問題になります。特定のファイルシステムの設計に応じて、そのデータを含むファイルまたは領域も断片化される可能性があります (上記の「通常の」ファイルの場合と同様)。これは、それらのファイルまたは領域内で維持される実際のデータレコードの断片化とは無関係です。[5]
一部のファイルシステム（ NTFS [c]やHFS / HFS Plus [6]など）では、このデータを最適化するために必要な照合/並べ替え/圧縮は、ファイルシステムの使用中に簡単には実行できません。[7]
否定的な結果
ファイルシステムの断片化は、通常ファイルシステムが置かれるシーケンシャルアクセス速度と回転待ち時間（およびそれほどではないがシーク時間）の間の格差が拡大しているため、消費者向けハードディスクドライブではより問題になります。 [8]そのため、断片化はファイルシステムの研究と設計における重要な問題です。断片化の抑制は、ファイルシステムのディスク上のフォーマットだけでなく、その実装にも大きく依存します。[9]ファイルシステムの断片化は、機械的なシーク時間が関係しないため、ソリッドステートドライブのパフォーマンスにそれほど影響しません。[10]ただし、ファイルシステムは、ファイルの非連続部分ごとに追加のメタデータを保存する必要があります。メタデータの各部分自体がスペースを占有し、処理能力とプロセッサ時間を必要とします。最大断片化制限に達すると、書き込み要求は失敗します。[10]
単純なファイルシステムベンチマークでは、現実的な経年変化や断片化をモデル化することが難しいため、断片化係数は省略されることが多い。むしろ、比較を簡単にするために、ファイルシステムベンチマークは空のファイルシステムで実行されることが多い。そのため、結果は実際のアクセスパターンとは大きく異なる可能性がある。[11]
緩和
断片化に対処するために、いくつかの手法が開発されています。これらは通常、事前対応型と遡及型の 2 つのカテゴリに分類できます。アクセス パターンを予測することが難しいため、これらの手法はほとんどの場合、本質的にヒューリスティックであり、予期しないワークロードが発生するとパフォーマンスが低下する可能性があります。
断片化を防ぐ
プリエンプティブ技術は、ディスクにデータが書き込まれるときに断片化を最小限に抑えようとします。最も単純なのは、新しいブロックを新しいフラグメントに割り当てるのではなく、可能な場合は既存のフラグメントにデータを追加することです。
今日のファイルシステムの多くは、アクティブに追加されるファイルに、エクステントと呼ばれるより長いチャンク、または異なる空き領域フラグメントからのチャンクを事前に割り当てようとします。これにより、複数のファイルが同時に追加されるときにファイルの断片化が大幅に回避され、ファイルが過度に絡み合うことが回避されます。[9]
変更対象となるファイルの最終的なサイズがわかっている場合は、ファイル全体のストレージを事前に割り当てることができます。たとえば、Microsoft Windows の スワップ ファイル(ページ ファイル) は通常の操作で動的にサイズが変更されるため、断片化が進む可能性があります。同じ最小サイズと最大サイズのページ ファイルを指定して、ファイル全体を効果的に事前に割り当てることで、これを防ぐことができます。
BitTorrentやその他のピアツーピア ファイル共有アプリケーションは、ダウンロードを開始するときにファイルに必要なスペース全体を事前に割り当てることで断片化を制限します。[12]
比較的最近の技術としては、XFS、HFS+ [13]、ZFSにおける遅延割り当てがある。同じ技術は、reiser4およびext4では allocate-on-flush とも呼ばれる。ファイルシステムへの書き込み時に、ファイルシステムブロックは予約されるが、特定のファイルの場所はまだ決定されていない。その後、メモリ不足やトランザクションコミットの結果としてファイルシステムが強制的に変更をフラッシュすると、アロケータはファイルの特性についてよりよく理解している。このアプローチを採用しているファイルシステムのほとんどは、単一のディレクトリ内のファイルを連続してフラッシュしようとする。単一のディレクトリからの複数の読み取りが一般的であると仮定すると、参照の局所性が向上する。[14] Reiser4 は、ディレクトリハッシュテーブルに従ってファイルのレイアウトも順序付けするため、ファイルが自然なファイルシステムの順序 ( readdirによって指定) でアクセスされている場合、ファイルは常に順番に読み取られる。[15]
デフラグ
遡及的技術は、断片化、または断片化の発生後の悪影響を軽減しようとします。多くのファイル システムには、ファイルの断片を並べ替えるデフラグツールが用意されており、ディレクトリまたはディレクトリ ツリー内の小さなファイル、またはディスク上のファイル シーケンスを互いに近づける ことで、ファイルの断片の分散を減らす (つまり、連続性または参照の局所性を向上させる) こともあります。
HFS Plusファイルシステムは、ファイルを開くときに、サイズが20MiB未満で8つ以上のフラグメントに分割されたファイルを透過的にデフラグします。 [16]
現在は廃止された Commodore Amiga Smart File System (SFS) は、ファイルシステムの使用中に自動的にデフラグを実行します。デフラグ プロセスは、ほぼ完全にステートレス (作業中の場所を除く) であるため、即座に停止および開始できます。デフラグ中は、メタデータと通常のデータの両方でデータの整合性が確保されます。
参照
注記
- ^ NTFSやext2 +などの一部のファイル システムでは、特別な目的のために空の連続領域を事前に割り当てる場合があります。
- ^ 削除されたファイルが占めていたスペースをほとんどそのまま残すという慣行のおかげで、復元プログラムが機能することができました。復元プログラムは、ディレクトリから名前が削除されたが、内容がまだディスク上に残っているファイルを復元するだけです。
- ^ NTFSはボリュームの12.5%を「MFTゾーン」用に予約しますが、そのスペースが他のファイルで必要になったときのみ有効です。(つまり、ボリュームが87.5%以上になると、断片化されていないMFTは保証されなくなります。) [5]
参考文献
- ^ Fisher, Ryan (2022-02-11). 「SSDをデフラグするべきか？」PC Gamer . 2022-02-18時点のオリジナルよりアーカイブ。2022-04-26閲覧。
- ^ http://www.8bs.com/hints/083.txt - 拡張できないエラーの説明
- ^ http://8bs.com/mag/1to4/basegd1.txt - 拡張できないエラーによりデータが失われる可能性がある
- ^ Douceur, John R.; Bolosky, William J. (1999 年 6 月). 「ファイルシステムの内容に関する大規模な調査」. ACM SIGMETRICS パフォーマンス評価レビュー. 27 (1): 59– 70. doi : 10.1145/301464.301480 .
- ^ ab 「NTFS がマスター ファイル テーブル (MFT) 用に領域を予約する方法」。learn.microsoft.com。Microsoft。2022年10月 22 日閲覧。
- ^ 「DiskWarrior in Depth」. Alsoft . 2022年10月22日閲覧。
- ^ 「デフラグによる Windows 2000 のピークパフォーマンスの維持」。learn.microsoft.com。Microsoft。2022年10 月 22 日閲覧。
- ^ Kryder, Mark H. (2006-04-03). 将来のストレージ技術: 地平線の向こう側(PDF) . ストレージ ネットワーキング ワールド カンファレンス。Seagate Technology。2006年 7 月 17 日時点のオリジナル(PDF)からアーカイブ。
- ^ ab McVoy, LW; Kleiman, SR (1991 年冬)。「 UNIXファイル システムからのエクステントのようなパフォーマンス」( PostScript )。USENIX winter '91の議事録。テキサス州ダラス: Sun Microsystems, Inc.、 pp. 33– 43。2006年 12 月 14 日に取得。
- ^ ab Hanselman, Scott (2014 年 12 月 3 日)。「本当の完全な話 - Windows は SSD を最適化しますか?」Scott Hanselman のブログ。
- ^ Smith, Keith Arnold (2001 年 1 月)。「ワークロード固有のファイル システム ベンチマーク」(PDF)。マサチューセッツ州ケンブリッジ:ハーバード大学。2004年 11 月 17 日のオリジナル(PDF)からアーカイブ。2006年 12 月 14 日に取得。
{{cite journal}}:ジャーナルを引用するには|journal=(ヘルプ)が必要です - ^ Layton, Jeffrey (2009 年 3 月 29 日)。「ext3 から ext4 へ: Theodore Ts'o 氏へのインタビュー」。Linux Magazine。QuinStreet。2009年 4 月1日時点のオリジナルよりアーカイブ。
- ^ Singh, Amit (2004 年 5 月)。「HFS Plus ボリュームの断片化」。Mac OS X 内部。2012 年 11 月 18 日時点のオリジナルよりアーカイブ。2009年 10 月 27 日閲覧。
- ^ Sweeney, Adam; Doucette, Doug; Hu, Wei; Anderson, Curtis; Nishimoto, Mike; Peck, Geoff (1996 年 1 月)。「XFS ファイル システムのスケーラビリティ」(PDF)。USENIX 1996 年年次技術会議の議事録。カリフォルニア州サンディエゴ: Silicon Graphics。2006年 12 月 14 日に取得。
- ^ Reiser, Hans (2006-02-06). 「Reiser4 ファイルシステム」。Google TechTalks。2011年 5 月 19 日時点のオリジナルよりアーカイブ。2006年 12 月 14 日閲覧。
- ^ Singh, Amit (2007). 「 12 HFS Plus ファイルシステム」。Mac OS X 内部: システムアプローチ。Addison Wesley。ISBN 0321278542。
さらに読む
- Smith, Keith; Seltzer, Margo. ファイルレイアウトとファイルシステムのパフォーマンス(PDF) (論文)。ハーバード大学。