7

As you can read here , ext4 file system has an extent feature that groups blocks into extents. Each of them can have up to 128MiB contiguous space. In e4defrag , there are lines similar to the following: 

[325842/327069]/file: 100% extents: 100 -> 10 [ OK ]

The size of the file is around 150MiB. So according to the wiki page, there should be 2 extents instead of 10.

  1. Does anyone know why the extents are 15MiB instead of 128MiB?
  2. Is there a a tool that can check the exact extent size?
  3. How can I change the size so it could be 128MiB?
Improve this question

2 Answers 2

Reset to default
2

I think your question is based on an incorrect premise.

Basically ... your extents are 128 MB in size, however e4defrag took the file, copied its data, found that the copy had 5 extents rather than 10 extents and so it called this a "success" and pointed the inode at the copied data and then freed up the original data. If this happens, it prints "10 -> 5".

(Now, it's also possible that it could come up the copied data having more extents, in which case it deletes the copy and leaves things as-is, and it prints "10 -> 10".)

The fuller your disk is, the less likely e4defrag is to shrink a file to the "minimum" number of extents that one might calculate based on its size.

But don't expect e4defrag to perfectly defrag your disk -- it kind of makes a lazy attempt at it, one attempt per file (per file that has more than one extent, that is -- if it already has only one extent (or the minimum possible I guess) it quickly skips it) and if that attempt doesn't result in some sort of improvement it just leaves things as-is, and even if there is improvement it's not guaranteed to be the minimum number of extents possible. Re-running e4defrag may end up with some improvement after the first run, especially if some more space has been freed since the previous run, but subsequent runs past the first will likely very quickly run into diminishing returns.

Improve this answer
1

I think I know how it works.

I connected another disk to my machine because it has a big almost empty partition ~458G . I checked its free space via e2freefrag:

HISTOGRAM OF FREE EXTENT SIZES: Extent Size Range : Free extents Free Blocks Percent 64M... 128M- : 6 146233 0.12% 128M... 256M- : 5 322555 0.27% 256M... 512M- : 3 263897 0.22% 512M... 1024M- : 6 1159100 0.98% 1G... 2G- : 228 116312183 98.40%

It's just a contiguous free blocks. So because the partition is almost empty, there's lots of free space and you have 228 chunks of 1-2G.

I placed a big 2,5G file inside of the partition, and the table above changed a little bit:

HISTOGRAM OF FREE EXTENT SIZES: Extent Size Range : Free extents Free Blocks Percent 2M... 4M- : 5 5114 0.00% 64M... 128M- : 7 170777 0.14% 128M... 256M- : 1 64511 0.05% 256M... 512M- : 4 361579 0.31% 512M... 1024M- : 5 930749 0.79% 1G... 2G- : 227 116025495 98.16%

This doesn't tell anything about the allocated block extents, but it gave me some ideas. When I looked at the file in e4defrag, there was something like this:

# e4defrag -cv file <File> [ext 1]: start 34816: logical 0: len 32768 [ext 2]: start 67584: logical 32768: len 30720 [ext 3]: start 100352: logical 63488: len 32768 [ext 4]: start 133120: logical 96256: len 30720 [ext 5]: start 165888: logical 126976: len 32768 [ext 6]: start 198656: logical 159744: len 30720 [ext 7]: start 231424: logical 190464: len 32768 [ext 8]: start 264192: logical 223232: len 30720 [ext 9]: start 296960: logical 253952: len 32768 [ext 10]: start 329728: logical 286720: len 32768 [ext 11]: start 362496: logical 319488: len 32768 [ext 12]: start 395264: logical 352256: len 32768 [ext 13]: start 428032: logical 385024: len 32768 [ext 14]: start 460800: logical 417792: len 32768 [ext 15]: start 493568: logical 450560: len 30720 [ext 16]: start 557056: logical 481280: len 32768 [ext 17]: start 589824: logical 514048: len 32768 [ext 18]: start 622592: logical 546816: len 32768 [ext 19]: start 655360: logical 579584: len 32768 [ext 20]: start 688128: logical 612352: len 32768 [ext 21]: start 720896: logical 645120: len 622

The number 32768 means blocks (4K), which equals to 128MiB. Some of them have fewer blocks and I don't know why because the filesystem is empty and I think all the extents should have 32768 blocks.

Anyway I checked the main partition to see its free space, and there was something like this:

HISTOGRAM OF FREE EXTENT SIZES: Extent Size Range : Free extents Free Blocks Percent 4K... 8K- : 3955 3955 0.06% 8K... 16K- : 3495 8194 0.13% 16K... 32K- : 2601 13165 0.20% 32K... 64K- : 2622 28991 0.45% 64K... 128K- : 2565 58267 0.90% 128K... 256K- : 1576 71371 1.11% 256K... 512K- : 1331 118346 1.83% 512K... 1024K- : 1058 190532 2.95% 1M... 2M- : 1202 444210 6.89% 2M... 4M- : 1211 884489 13.71% 4M... 8M- : 1249 1803998 27.97% 8M... 16M- : 622 1643226 25.48% 16M... 32M- : 198 1024999 15.89% 32M... 64M- : 16 163082 2.53%

As you can see, there's no free contiguous blocks that could provide 128M (and more) space and that's why they've written on the wiki that you can have extents "up to" 128M.

I'm not sure why the file in question has 10 extents because there's still 16 chunks that are at least 32M.

Improve this answer
2
  • +1 for the analysis but you haven't fully answered your own questions, only really number 2. Maybe you could separate them out and ask them independently on this site so that we can get some more clarity on why it allocated what it did and how to control it. Commented Jul 25, 2015 at 1:13
  • 1: as files, free space can also be fragmented. Look at the output of e2freefrag. The file system (ext4) is designed to deal with chunks up to 128M, but if your free contiguous space is less than the value, you won't get an extent that is equal to 128M. So if you have some free 10M extents (that's the max free contiguous space), and you want to write 100M file, you get that file in 10 extents instead of one, and the file is fragmented at least from ext4's point of view. 3: Simply don't store too much data on the drive, or try to separate big files from small files (different partitions). Commented Jul 25, 2015 at 7:33

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.