答え1
より混乱するのは、2つのタイプのフラグメントと3つのタイプのフラグメントがあるということです。
断片化されたファイルは、複数のブロック（または断片、各断片がスコープになる可能性があります）に格納されるファイルなので、ファイルを順次読み取ると、オペレーティングシステムはディスク上のさまざまな場所からすべての断片を読み取る必要があるため、遅くなります。ファイル読み取り速度。 ext4fsのアルゴリズムは、ファイルにブロックをできるだけ連続的に割り当てることで、これが発生しないようにします。複数の範囲を持つファイルを断片化したファイルと呼びます。ただし、ファイルは、スコープではなく連続ブロックのリストである単一のフラグメント（つまり分割されていない）として保存することもできます。これがフラグメントと範囲が関連する方法です。
フラグメントは、チャンクより小さいファイルの最後のチャンクでも、他のフラグメントと一緒にチャンク全体にフラグメントとして格納されるチャンクより小さいファイルでもあります。ブロックサイズが大きく、小さなファイルが多い場合は、単一のブロックに複数のファイルを保存することで、大量のスペースを節約し、パフォーマンスを向上させることができます。特に、ブロックを共有するすべてのファイルを読み取ろうとする場合はさらにそうです。
ファイルシステムの観点からは、内部断片化と外部断片化がある可能性があります。
内部断片化は単一ファイル内で行われ、上記の最初の断片化タイプと同じです。
外部断片化は、関連ファイルがすべて1つのディレクトリにあり、ディスク全体に分散されている場合に発生します。ディレクトリ内のすべてのファイルを読み取ろうとすると、内部断片化と同じように多くのパフォーマンス問題が発生する可能性があります。 ext4fsアルゴリズムはまた、同じディレクトリ内の他のファイルと同じシリンダグループ内のファイルにブロックを割り当てようとし、外部断片化を最小化しようとします。
歴史的記録：
Linux ext4fsはext3fs、ext2fs、extfsの進歩です。 extfsはUFSに基づいていますが、ベースではありません。 UFSはBSD Fast File System（FFS）に基づいています。上記のアルゴリズムはFFSのコアアルゴリズムであり、主にext4に存在しますが、FFSの他の多くのアルゴリズム（特に回転遅延を処理するアルゴリズム）は廃止され、UFSで廃棄される可能性があります。上記の用語のいくつかは（少なくとも）Linux第2世代であり、用語自体は変更された可能性がありますが、アルゴリズムはそのまま残ります。
FFSのシリンダーグループは、最初はトラックとセクター（回転待ち時間の最適化のため）に関連付けられていますが、実際には隣接するシリンダーだけです。ブロックは少なくとも30年間トラック/セクターにはっきりとマッピングされておらず、おそらくフロッピーディスクが広く普及してからはなかったでしょう。ただし、シリンダーグループは依然として連続ブロックグループであり、ナビゲーション時間を最適化するのに役立ちます。ナビゲーション時間はSSDとは関係ありませんが、連続ブロック割り当ては依然として役立つ可能性があります。
シリンダーグループの最適化はほとんど副作用ですが、意図的です。なぜなら、 inode はシリンダグループに属し、ディレクトリの inode は順次割り当てられる傾向があり、ディレクトリの inode にブロックを割り当てようとするからです。同じシリンダーグループ。
シリンダグループは、断片化によって引き起こされるパフォーマンスの問題を軽減するために使用される唯一のアルゴリズムではありません。 FFSもファイル内でより大きな連続ブロック割り当てを得るためにブロック割り当てを遅らせようとします。
UNIXでは、「断片」という用語は常に不注意に使用され、文脈を注意深く読まないと、どのタイプの断片を参照しているかはほとんどまたはまったく明確ではありません。 BSD と Linux の両方について複数の歴史的文書を検索して参照した結果、内部または外部の断片化という用語の正式な定義が見つからず、その使用法は決して修正されていないように見え、「断片化」という用語自体が時々使用されていました.両方のタイプを同時に参照します。
答え2
あなたはすでに引用しています源泉これは範囲が何であるかを説明します。
フラグメントの場合、ブロックのセグメンテーションです。この概念はFFSで導入され、UFSにもまだ存在しますが、EXT4にはありません。
源泉：
ファイルが作成または拡張されると、完全な論理ブロックまたはフラグメントと呼ばれる論理ブロックの一部にディスク領域が割り当てられます。ファイルにディスク容量が必要な場合は、ブロック全体が最初に割り当てられ、次にブロックの1つ以上のフラグメントが残りの部分に割り当てられます。小さなファイルの場合、割り当てはフラグメントから始まります。
ブロック全体の代わりにブロックフラグメントをファイルに割り当てる機能は、ブロックの未使用の穴によるディスクスペースの断片化を減らし、スペースを節約します。
UFSファイルシステムを作成するときのフラグメントサイズを定義します。デフォルトの断片サイズは1KBです。各ブロックは1、2、4、または8つのフラグメントに分割できるため、フラグメントサイズは8192バイトから512バイト（4KBファイルシステムのみ）です。下限は実際には通常512バイトのディスクセクタサイズに関連しています。
テラバイト級ファイルシステムの場合、フラグメントサイズはファイルシステムブロックサイズと同じでなければなりません。
https://recoverhdd.com/blog/ufs1-and-ufs2-file-systems.html
FFSの主な目的は、ディレクトリ内のすべてのコンテンツ（データとメタデータ）を単一のシリンダーグループに統合することです。ディスク表面全体にデータが過度に分散し、断片化レベルが大幅に減少します。ただし、ディスクサイズとディスクに格納されているファイルサイズの急激な増加は、適切なレベルのパフォーマンスを維持するためにブロックサイズを増やすため、このソリューションはもはや有効ではありません。したがって、小さなファイルをたくさん保存すると、多くのスペースを占めることになります。
これにより、開発者にファイルシステムの開発を強制し、FFSに基づいて改訂されたファイルシステム「UFS1」が作成され、後で安定性とスピードを提供するために改訂された「UFS2」が作成されました。ブロックはフラグメントに分割されるため、これらのフラグメントはファイルの最終バイトを格納するために使用されます（ブロック全体は以前に割り当てられました）。そしていくつかの新しい技術。
繰り返しますが、この概念はEXT3 / 4には存在しません。
ext3fsはブロック断片化をサポートしていないため、バイトファイルは4096ブロック全体を使用します。
対照的に、たとえばUFSはブロック内の4つのフラグメントをサポートしているため、小さなファイルはext3fsのようにファイルシステムをすばやく埋めません。
数百万の1KBファイルを収容するためのext4パーティションの最適化
AFAIK、ext4はあなたがしていることにまったく良い選択ではありません。ブロックサブ割り当てはサポートされていません。。実際には、UFS2またはBtrFSの使用を検討する必要があります。
EXT3/4 FS は、# dumpe2fsブロックサイズと同じフラグメントサイズを表示します。
# dumpe2fs /dev/sde1
(...)
Block size: 4096
Fragment size: 4096
(...)