Minimizing fragmentation in ext4, fallocate not enough?

I noticed that several random IO-heavy Firefox files got fragmented easily. Our cache suffers most.
The cache works by creating a flat file and storing fixed-size entries in it. I though if I fallocate() the file first, then all of the writes within the allocated area would not cause additional fragmentation.

This doesn't seem to completely cure fragmentation with ext4 in 2.6.33. If I allocate a 4mb file, it gets more and more fragmented over time. fallocate() does reduce fragmentation, but not as much as I expected.

ps2. Does running filefrag on a directory mean anything in ext4?

Quoted 10 lines · Taras Glek

I noticed that several random IO-heavy Firefox files got fragmented easily. Our cache suffers most. The cache works by creating a flat file and storing fixed-size entries in it. I though if I fallocate() the file first, then all of the writes within the allocated area would not cause additional fragmentation.

This doesn't seem to completely cure fragmentation with ext4 in 2.6.33. If I allocate a 4mb file, it gets more and more fragmented over time. fallocate() does reduce fragmentation, but not as much as I expected.

Have you checked filefrag immediately after fallocating the file? Is it OK?

It may be that the issue is that an fallocate()'d file is using "unwritten extents" and converting these extents to "normal" extents may cause apparent fragmentation. However, depending on which version of e2fsprogs/filefrag you are using, it may well be that these extents only appear to be fragmented due to the different extent types.

Quoted 1 line

ps2. Does running filefrag on a directory mean anything in ext4?

With newer e2fsprogs using FIEMAP and kernels it should be possible to get useful filefrag data from a directory. Older kernels/e2fsprogs using FIBMAP will just fail outright.

Quoted 14 lines · Andreas Dilger

Quoted 10 lines · Taras Glek

I noticed that several random IO-heavy Firefox files got fragmented easily. Our cache suffers most. The cache works by creating a flat file and storing fixed-size entries in it. I though if I fallocate() the file first, then all of the writes within the allocated area would not cause additional fragmentation.

This doesn't seem to completely cure fragmentation with ext4 in 2.6.33. If I allocate a 4mb file, it gets more and more fragmented over time. fallocate() does reduce fragmentation, but not as much as I expected.

Have you checked filefrag immediately after fallocating the file? Is it OK?

Quoted 6 lines

It may be that the issue is that an fallocate()'d file is using "unwritten extents" and converting these extents to "normal" extents may cause apparent fragmentation. However, depending on which version of e2fsprogs/filefrag you are using, it may well be that these extents only appear to be fragmented due to the different extent types.

Agreed, please include filefrag (-v) output right after it's fallocated, and also when you see this fragmentation, and then we'll have a better idea about what you're seeing. And, the newer the filefrag the better. :)

Quoted 21 lines · Eric Sandeen

Quoted 14 lines · Andreas Dilger

Quoted 10 lines · Taras Glek

I noticed that several random IO-heavy Firefox files got fragmented easily. Our cache suffers most. The cache works by creating a flat file and storing fixed-size entries in it. I though if I fallocate() the file first, then all of the writes within the allocated area would not cause additional fragmentation.

This doesn't seem to completely cure fragmentation with ext4 in 2.6.33. If I allocate a 4mb file, it gets more and more fragmented over time. fallocate() does reduce fragmentation, but not as much as I expected.

Have you checked filefrag immediately after fallocating the file? Is it OK?

Quoted 6 lines

It may be that the issue is that an fallocate()'d file is using "unwritten extents" and converting these extents to "normal" extents may cause apparent fragmentation. However, depending on which version of e2fsprogs/filefrag you are using, it may well be that these extents only appear to be fragmented due to the different extent types.

Quoted 4 lines

Agreed, please include filefrag (-v) output right after it's fallocated, and also when you see this fragmentation, and then we'll have a better idea
about what you're seeing. And, the newer the filefrag the better. :)

Thanks for clarification. Turns out ext4 is performing as expected, nevermind my previous message.

I was confused by discrepancy in number of extents reported by filefrag 1.41.10 with/without -v flag.

filefrag _CACHE_003_
_CACHE_003_: 17 extents found
filefrag -v _CACHE_003_
Filesystem type is: ef53
File size of _CACHE_003_ is 4194304 (1024 blocks, blocksize 4096)
ext logical physical expected length flags

   0       0   232448             128
   1     128   232576               1 unwritten
   2     129   232577              95
   3     224   232672               1 unwritten
   4     225   232673              31
   5     256   232704               1 unwritten
   6     257   232705              63
   7     320   232768               1 unwritten
   8     321   232769              95
   9     416   232864               1 unwritten
  10     417   232865             255
  11     672   233120               1 unwritten
  12     673   233121             191
  13     864   233312               1 unwritten
  14     865   233313             127
  15     992   233440               3
  16     995   233443              29 unwritten,eof

_CACHE_003_: 1 extent found

Thanks,
Taras