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
We do not disturb regular inode allocations in any way, it just
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.