On Wed, Jan 29, 2014 at 11:40 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > On Wed, Jan 29, 2014 at 11:21:07PM +0400, Azat Khuzhin wrote: >> >> Workload: there are _many_ files that don't deleted, append/full >> rewrite/create only, lifetime 1-2 years: >> >> 8988871 inodes used (2.09%, out of 429817856) >> 1012499 non-contiguous files (1.7%) >> 2039 non-contiguous directories (0.0%) >> # of inodes with ind/dind/tind blocks: 0/0/0 >> Extent depth histogram: 8616444/372389/30 >> # about 99% blocks in use wrong information, I shrinked fs before >> this, to minimal size > > > Shrinking the file system is known to result in really horrible > fragmentation. Part of this is because resize2fs has a really stupid > block allocator, but if you're going to shrink the file system to > minimal size the results can be truly catastrophic from a file > fragmentation point of view. (Imagine my horror when I was told that > Fedora was creating bootable CD-ROM's by creating a large file system > image, and then using resize2fs -M to shink it to minimal size. Not > only would the file layout be definitely non-optimal, but worse, > CD-ROM drives are not know for fast seek times!) Thanks, good to know. Anyway, that fs already not used, it was once for migration, and on new fs most of files already rewritten. > > We can probably make resize2fs smarter in the case where we are > shrinking the file system slightly (say, to make room for LVM /thinp > metadata when coverting a whole disk file system to one which is being > managed via LVM). But I'm not sure it's ever going to be worth it > making resize2fs -M generate an optimal, minimally fragmented file > system image. > > - Ted -- Respectfully Azat Khuzhin -- 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
