Re: [PATCH 2/2] resize2fs: fix overhead calculation for meta_bg file systems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Sep 5, 2012 at 2:32 PM, Kevin Liao <kevinlia@xxxxxxxxx> wrote:
> 2012/9/4 Theodore Ts'o <tytso@xxxxxxx>:
>> On Tue, Sep 04, 2012 at 09:59:55AM +0800, Yongqiang Yang wrote:
>>> Hi Kevin,
>>>
>>>   Ted has sent out the patches on online resizing for meta_bg and
>>> 64bits, so you can have a try again. It seems that the bug in
>>> e2fsprogs has been fixed.
>>
>> Make sure you use the latest version of the kernel patches that I just
>> sent out.  There quite a number of bugs in the Yongqiang's original
>> patch set which I tripped over while I was testing 64-bit resize ---
>> and please note that there are definitely still rough edges
>> (especially for in cases where the file system was created < 16TB, but
>> with the 64-bit feature and resize_inode features enabled).  There may
>> also be bugs for the straightforward case of resizing very large file
>> systems.
>>
>> So while I very much appreciate users giving the code a try and
>> sending us feedback, please do think twice before using this code on
>> file systems with data that hasn't been backed up recently.  (Of
>> course, being good System Administrators you are all keeping --- and
>> verifying --- regular backups, right?  :-)
>>
>> Regards,
>>
>>                                                 - Ted
>
> I had done some simple and quick test. The following is the result.
>
> Kernel: 3.4.7 + 5 patches
> e2fsprogs: 1.42.5 + 2 patches
>
> The format command I used is:
> mke2fs -t ext4 -m0 -b 4096 -F -O 64bit,meta_bg,^resize_inode /dev/md0 nnnn
>
> Case 1: Simplly resize
> 1st step: resize from 14T to 18T => ok
> 2nd step: resize from 18T to 20T => ok (calculate_minimum_resize_size
> issue gone)
> 3rd step: resize from 20T to 21T => ok
>
> Case 2: case 1 + file read-write (just like Anssi did)
> 1st step: resize from 14T to 20T (5368709120 blocks) => ok
> 2nd step: resize from 20T to 5368709170 blocks => same kernel bug_on
>
> Case 3: case 2 + Yongqiang's 2 patches
> 1st step: resize from 14T to 20T (5368709120 blocks) => ok
> 2nd step: resize from 20T to 5368709170 blocks => ok
>
> Basically I think the resize funtionality should be ok. However I also
> observe some performance drop. That is, the time needed for mke2fs,
> mount and e2fsck are longer than before. Here is some detailed data:
>
> For 12TB with 64bit,meta_bg,^resize_inode
> mke2fs: 54.699s
> mount: 12.108s
> e2fsck: 1m52.027s
>
> For 12TB without 64bit,meta_bg,^resize_inode
Did you mean without 64bit and without meta_bg OR with without 64bit
and with meta_bg?

I am guessing you meant without 64bit and without meta_bg, am I right?
Yongqiang.
> mke2fs: 39.763s
> mount: 0.897s
> e2fsck: 1m17.554s
>
> For 20TB with 64bit,meta_bg,^resize_inode
> mke2fs: 1m25.090s
> mount: 19.992s
> e2fsck: 2m55.048s
>
> For 20TB without 64bit,meta_bg,^resize_inode
> mke2fs: 1m3.660s
> mount: 1.458s
> e2fsck: 1m56.055s
>
> Yongqiang had told me previously that it may be caused by using
> meta_bg. I am still wondering is there anything we can do to improve
> the peroformance? Thanks a lot.
>
> Regards,
> Kevin Liao



-- 
Best Wishes
Yongqiang Yang
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux