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.