FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 10-05-2011, 05:54 PM
"Richard W.M. Jones"
 
Default Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide

On Wed, Oct 05, 2011 at 10:42:37AM -0500, Eric Sandeen wrote:
> On 10/5/11 9:58 AM, Eric Sandeen wrote:
> > On 10/4/11 6:53 PM, Ric Wheeler wrote:
>
> ...
>
> >> Note that ext4 has a new feature that allows inodes to be initialized in the
> >> background, so you will see much quicker mkfs.ext4 times as well
> >
> > 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.
> >
> > 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.
>
> Sorry, Lukas reminds me that this should already be the default mode, with a
> new enough kernel and new enough e2fsprogs. Rawhide should meet those criteria.

lazy_itable_init is always on by default now?

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-05-2011, 09:32 PM
Farkas Levente
 
Default Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide

On 10/05/2011 05:42 PM, 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.
>>
>> 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.
>
> Sorry, Lukas reminds me that this should already be the default mode, with a
> new enough kernel and new enough e2fsprogs. Rawhide should meet those criteria.

yes i know it's not rhel list, but still is it working on rhel-6?

--
Levente "Si vis pacem para bellum!"
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-06-2011, 02:34 PM
Eric Sandeen
 
Default Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 11:40 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org