[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAGBYx2bdaGRMLmWiz752AGs9EfygXQU3nEMYxLNCCjVYkiuG-A@mail.gmail.com>
Date: Wed, 17 Aug 2011 15:28:28 +0800
From: Yongqiang Yang <xiaoqiangnk@...il.com>
To: Justin Maggard <jmaggard10@...il.com>
Cc: Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: New resize interface implementation
On Tue, Aug 16, 2011 at 8:22 AM, Justin Maggard <jmaggard10@...il.com> wrote:
> Hi,
Hi Justin,
> I saw your patch, and I am excited to see online resize support of very
> large filesystems. I was hoping you could answer a few additional questions
> for me.
My pleasure.
> Does this patch set combined with your e2fsprogs patch add 64-bit resize
> support now, or does it just make it easier to add later?
YES. e2fsprgos's patch is ready too.
> If I am making a 64-bit ext4 filesystem today (20TB), and hoping to resize
> it next year to 30TB what features should I set? In my searching it sounded
> like maybe I would need meta_bg, but it is not compatible with the default
> resize_inode.
You can understand meta_bg here http://linuxsoftware.co.nz/wiki/ext4.
Now, ext4 with meta_bg does not support resize. It is in ext4's TODO list.
The feature you should set is resize_inode.
> Also, if I am making a <16TB filesystem today, should I turn on the 64-bit
> flag in order to expand to >16TB in the future?
Yes. You should turn on 64 bit feature. If the block number is 32
bit, the size it can support is 2^32 * 2^(log blocksize), 4K
blocksize as an example, it maximum size of a filesystem is 2^32 *
2^12 = 2^44 = 16TB.
> Thank you for your time,
You are welcome.
> -Justin
> On Wed, Aug 10, 2011 at 8:28 PM, Yongqiang Yang <xiaoqiangnk@...il.com>
> wrote:
>>
>> Hi all,
>>
>> This patch series adds new resize implementation to ext4.
>>
>> -- What's new resize implementation?
>> It is a new online resize interface for ext4. It can be used via
>> ioctl with EXT4_IOC_RESIZE_FS and a 64 bit integer indicating size
>> of the resized fs in block.
>>
>> -- Difference between current resize and new resize.
>> New resize lets kernel do all work, like allocating bitmaps and
>> inode tables and can support flex_bg and BLOCK_UNINIT features.
>> Besides these, new resize is much faster than current resize.
>>
>> Below are benchmarks I made on my personal computer, fses with
>> flex_bg size = 16 were resized to 230GB evry time. The first
>> row shows the size of a fs from which the fs was resized to 230GB.
>> The datas were collected by 'time resize2fs'.
>>
>> new resize
>> 20GB 50GB 100GB
>> real 0m3.558s 0m2.891s 0m0.394s
>> user 0m0.004s 0m0.000s 0m0.394s
>> sys 0m0.048s 0m0.048s 0m0.028s
>>
>> current resize
>> 20GB 50GB 100GB
>> real 5m2.770s 4m43.757s 3m14.840s
>> user 0m0.040s 0m0.032s 0m0.024s
>> sys 0m0.464s 0m0.432s 0m0.324s
>>
>> According to data above, new resize is faster than current resize in
>> both
>> user and sys time. New resize performs well in sys time, because it
>> supports BLOCK_UNINIT and adds multi-groups each time.
>>
>> -- About supporting new features.
>> YES! New resize can support new feature like bigalloc and exclude bitmap
>> easily. Because it lets kernel do all work.
>>
>> [PATCH 01/13] ext4: add a function which extends a group without
>> [PATCH 02/13] ext4: add a function which adds a new desc to a fs
>> [PATCH 03/13] ext4: add a function which sets up a new group desc
>> [PATCH 04/13] ext4: add a function which updates super block
>> [PATCH 05/13] ext4: add a structure which will be used by
>> [PATCH 06/13] ext4: add a function which sets up group blocks of a
>> [PATCH 07/13] ext4: add a function which adds several group
>> [PATCH 08/13] ext4: add a function which sets up a flex groups each
>> [PATCH 09/13] ext4: enable ext4_update_super() to handle a flex
>> [PATCH 10/13] ext4: pass verify_reserved_gdb() the number of group
>> [PATCH 11/13] ext4: add a new function which allocates bitmaps and
>> [PATCH 12/13] ext4: add a new function which adds a flex group to a
>> [PATCH 13/13] ext4: add new online resize interface
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
Best Wishes
Yongqiang Yang
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists