On Tue, Aug 16, 2011 at 8:22 AM, Justin Maggard <jmaggard10@xxxxxxxxx> 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@xxxxxxxxx> > 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@xxxxxxxxxxxxxxx >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html