Here's an interesting data point. Using Chris Mason's compilebench: http://oss.oracle.com/~mason/compilebench If I use: ./compilebench -D /mnt -i 2 -r 0 on a 4GB machine such that I have plenty of memory (and nothing gets forced disk due to memory pressure), I don't see hardly any of the small file fragmentation problem (0.8% of the inodes in use on the filesystem. This is with your patch applied. However, if I use: ./compilebench -D /mnt -i 10 -r 0 so that data blocks are getting pushed out due to memory pressure, then I see plenty of non-contiugous inodes (8.1% of the inodes in use on the filesystem). So with your patch applied, it seems that we still have a problem related to delayed allocation and how the VM system is doing its page cleaning. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
