Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide

[Eric Sandeen]

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.
>