On Tue, Aug 16, 2011 at 8:22 AM, Justin Maggard [off-list ref] 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 [off-list ref]
wrote:

quoted

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@vger.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html