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

[Eric Sandeen]

On 10/4/11 6:53 PM, Ric Wheeler wrote:
> On 10/04/2011 07:19 PM, Przemek Klosowski wrote:
>> On 10/03/2011 06:33 PM, Eric Sandeen wrote:
>>> On 10/3/11 5:13 PM, Richard W.M. Jones wrote:
>>>> On Mon, Oct 03, 2011 at 04:11:28PM -0500, Eric Sandeen wrote:
>>>>> testing something more real-world (20T ... 500T?) might still be interesting.
>>>> Here's my test script:
>>>>
>>>>     qemu-img create -f qcow2 test1.img 500T&&   \
>>>>       guestfish -a test1.img \
>>>>         memsize 4096 : run : \
>>>>         part-disk /dev/vda gpt : mkfs ext4 /dev/vda1
>> ...
>>>> At 100T it doesn't run out of memory, but the man behind the curtain
>>>> starts to show.  The underlying qcow2 file grows to several gigs and I
>>>> had to kill it.  I need to play with the lazy init features of ext4.
>>>>
>>>> Rich.
>>>>
>>> Bleah.  Care to use xfs? ;)
>> WHy not btrfs? I am testing a 24TB physical server and ext4 creation
>> took forever while btrfs was almost instant. I understand it's still
>> experimental (I hear storing virtual disk images on btrfs still has
>> unresolved performance problems) but vm disk storage should be fine.
>> FWIW I have been using btrfs as my /home at home for some time now;
>> so far so good.
> 
> Creating an XFS file system is also a matter of seconds (both xfs and btrfs do 
> dynamic inode allocation).
> 
> 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.

-Eric

> ric
>