Why kernel.org is slow: EXT3 file fragmentation?
Why kernel.org is slow: EXT3 file fragmentation?
Posted Jan 13, 2007 22:13 UTC (Sat) by jzbiciak (guest, #5246)In reply to: Why kernel.org is slow: EXT3 file fragmentation? by etienne_lorrain@yahoo.fr
Parent article: Why kernel.org is slow
The EXT2/EXT3 filesystem has a number of structures, such as block group bitmaps, that occur in a regular pattern over the surface of the disk. While ext2/ext3 try to minimize gaps in a file, these fixed structures do interrupt large files. So, in your case, you're probably hitting that. Furthermore, no amount of allocator smarts will make a fully contiguous file if it's larger than the distance between two block bitmaps.
Note that fragmenting a file in this manner tends not to be a performance issue since large linear reads still mostly read the file of interest, and skipping a few blocks doesn't typically cause a seek. That is why I imagine it's not widely considered an issue. It's quite a bit different than, say, the old MS-DOS first-fit policy that could cause a file to be literally spread piecemeal across the entire filesystem. That sort of fragmentation destroys performance.