17

私はGoogleファイルシステム(GFS)の論文を調べていましたが、GFSは遅延スペース割り当てを使用して内部の断片化を減らすと述べています。
遅延スペースが内部の断片化をどのように減らすか、誰かが説明できますか?

出典: http://research.google.com/archive/gfs-sosp2003.pdf

4

4 に答える 4

10

レイジー スペース割り当てでは、チャンク サイズ (GFS の場合、2003 年の論文によると 64 MB) のサイズのデータ​​が蓄積されるまで、スペースの物理的な割り当てが可能な限り遅延されます。つまり、ディスク上に新しいチャンクを割り当てる前の決定プロセスは、書き込まれるデータのサイズに大きく影響されます。他の特性に基づいてより多くのチャンクを割り当てるのではなく、待機するというこの設定により、内部断片化 (つまり、64 MB チャンクの未使用部分) の可能性が最小限に抑えられます。

Google の論文では、次のようにも述べています。したがって、ファイルの作成にも同じアプローチが適用されます。

これに類似しています: http://duartes.org/gustavo/blog/post/how-the-kernel-manages-your-memory

于 2014-02-12T19:53:29.583 に答える
1

論文全体を読んだわけではありませんが、次の断片が少しでも役立つことを願っています。

私が最初に尋ねる質問は、ファイル システムに大きなブロック サイズがあるとどのような影響があるかということです。FS ブロック サイズが 64MB であるとします。良いニュースは、適切な連続したチャンクをハードディスクに書き込む (シークごとにより多くのデータが書き込まれる)、間接ブロックに保持するメタデータが少ない、などです。悪いニュースは、内部の断片化です..ファイルが 1MB の場合、最小ブロック サイズは 64MB です、63MBの内部断片化があります。では、良いニュースを受け取り、悪いニュースを避けるにはどうすればよいでしょうか。

1 つの方法は、遅延スペース割り当てまたは遅延スペース割り当てを行うことです。ここでは、ブロック サイズを小さく (たとえば 1MB) 維持しますが、ディスクに書き込むときに、大量のデータ、つまり多くの 1MB のチャンクをまとめて書き込みます。このようにして、大きなブロック書き込みの利点を得ることができます。これは、インコア バッファに書き込むことを意味しますが、ディスクへの書き込みが完了したことを write() システム コールに伝えます...ちょうどバッファ キャッシュへの書き込みと同様です。

注: 実際のブロック割り当てを行う「時」が来たら、ディスク上のスペースを保証する必要があります。つまり、遅延ブロック割り当て => スペースの予約は書き込み時に行われますが、スペースの割り当ては後で十分なデータ ブロックがコア内に蓄積されたときに行われます。

于 2013-08-07T18:15:13.467 に答える
0

データは最初にバッファに書き込まれます。したがって、ファイルが作成された瞬間にメモリを割り当てるのではなく、実際の書き込みが発生するまで待機します。XFS http://en.wikipedia.org/wiki/XFS#Delayed_allocationのように

于 2014-01-03T22:20:59.013 に答える
0

作成時にファイルサイズを固定する必要はありません。そして、それをより大きなファイルに追加できます。これを参照できます。

于 2014-11-30T08:28:40.873 に答える