On 10/5/11 12:54 PM, Richard W.M. Jones wrote: > On Wed, Oct 05, 2011 at 09:58:59AM -0500, Eric Sandeen wrote: >> right; for large ext4 fs use (or testing), try >> >> # mkfs.ext4 -E lazy_itable_init=1 /dev/blah >> >> this will cause it to skip inode table initialization, and speed up >> mkfs a LOT. It'll also keep sparse test images smaller. >> >> IMHO this should probably be made default above a certain size. > > You almost preempted my question: Could I use this for every ext4 > filesystem I make? Honestly from a virt / libguestfs p.o.v. it sounds > like something we should always do. Yes, and sorry for the earlier confusion - it should be on by default for newer kernels + e2fsprogs. >> The tradeoff is that inode table initialization happens in >> kernelspace, post-mount - with efforts made to do it in the >> background, and not impact other I/O too much. > > Is there a circumstance where this is bad? I'm thinking perhaps a > case where you create a filesystem and immediately try to populate it > with lots of files. I do have some concerns about that. I think it will take some careful benchmarking to know for sure whether it is an issue. Commit bfff68738f1cb5c93dab1114634cea02aae9e7ba has a good summary of how it all works, and what some impact on early fs operations may be: > We do not disturb regular inode allocations in any way, it just do not > care whether the inode table is, or is not zeroed. But when zeroing, we > have to skip used inodes, obviously. Also we should prevent new inode > allocations from the group, while zeroing is on the way. For that we > take write alloc_sem lock in ext4_init_inode_table() and read alloc_sem > in the ext4_claim_inode, so when we are unlucky and allocator hits the > group which is currently being zeroed, it just has to wait. -Eric > Rich. > -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
