私を混乱させる質問があり、私の仕事は断片化を解決することです。
stat() for a file:
st_size = 10520
st_blksize = 4096
st_blocks = 24
st_blksize はファイル システムの一般的なブロック サイズであるといくつかの場所で読みましたが、この場合4096、そのファイルは に収まります。これは3 blocks、割り当てられているにもかかわらず、未使用のスペースがあること10520 / 512を20.5意味します。これは、このファイルに未使用のバイト3.5 blocksがあることを意味しますか (断片化)?1792
私が言及したように、私はこれをかなり読んで、矛盾するテキストをたくさん読んだので、誰かにこれをきっぱりと片付けてもらいたいです!
stat(2)あなたのプロジェクトがAPI レイヤーで実際に解決できるとは思いません。4096 バイトの長さのファイルの場合を考えてみましょう。512バイトのブロックを何度も繰り返し追加することによって作成されたと仮定します。書き込みごとに、1 つの 512 バイト ブロックを除いて、ファイル システムが完全にいっぱいであると仮定します。各書き込みに使用できる 512 バイトのブロックが、ディスク上のランダムに使用可能な場所にあると仮定します。
このファイルは 100% 断片化されています。2 つのブロックが互いに近接していません。
それでも、変数のみに基づく測定stat(2)では、ファイルのどこにも無駄なブロックがないことが示される可能性があります。
あなたの実際の質問に対する答えを突き止めようとしたとき、私はext3_write_begin()呼び出される前までたどり着きました.これがあなたの検索の出発点として役立つことを願っています.
アップデート
断片化を見つけることに興味がある場合は、開始する場所はプログラムbmapからのコマンドだと思います。debugfs(8)
debugfs: bmap sars_first_radio_show.zip 0
94441752
debugfs: bmap sars_first_radio_show.zip 1
94441781
debugfs: bmap sars_first_radio_show.zip 2
94441782
debugfs: bmap sars_first_radio_show.zip 3
94441783
debugfs: bmap sars_first_radio_show.zip 4
94441784
debugfs: bmap sars_first_radio_show.zip 5
94459905
debugfs: bmap sars_first_radio_show.zip 6
95126019
debugfs: bmap sars_first_radio_show.zip 7
95126020
debugfs: bmap sars_first_radio_show.zip 8
95126021
debugfs: bmap sars_first_radio_show.zip 9
95126022
debugfs:
これは、ファイルの最初の 10 ブロックを示していますsars_first_radio_show.zip。ブロックがすべて連続しているわけではないことがわかります: 944417{52,81,82,83,84}、94459905、951260{19,20,21,22}。
答えをスクリプト化するか、ライブラリルーチンを自分debugfs(8)で使用することができます。libext2fsこれまでの演習と比較すると、かなり複雑になりstat(2)ますが、答えは単なる漠然とした推測ではなく、何かを意味します。