On 2012-06-07, at 5:38 PM, Kees Cook wrote: > On Thu, Jun 7, 2012 at 3:54 PM, Ted Ts'o <tytso@xxxxxxx> wrote: >> On Thu, Jun 07, 2012 at 03:40:40PM -0700, Kees Cook wrote: >>> >>> FWIW, I was building the filesystem that triggered this as ext4: >>> >>> mkfs.ext4 -T default -m 0 -O ^huge_file,^flex_bg -E >>> discard,lazy_itable_init /dev/mapper/... >> >> Ouy of curiosity, was there a reason you chose those particular file >> system parameters? It's a surprising set, because if you're starting >> with a fresh file system, enabling flex_bg produces a more optimal >> file system layout. > > The intent of this was to create a small (64M) initial filesystem as > fast as possible that could be resized (to 3G) on the fly later. (The > performance of the filesystem did not need to be optimized, just the > speed of creation so that the create+mount would happen as fast as > possible, to unblock things waiting for this filesystem to exist.) Actually, flex_bg should improve mke2fs times, because the inode and block bitmaps are allocated contiguously on disk. Cheers, Andreas -- 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
