|| ||Yongqiang Yang <email@example.com> |
|| ||firstname.lastname@example.org |
|| ||[PATCH v5 00/15] ext4: add new online resize |
|| ||Fri, 23 Dec 2011 16:14:50 +0800|
|| ||Article, Thread
This is the 5th version of patch series adding new online resize 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'.
20GB 50GB 100GB
real 0m3.558s 0m2.891s 0m0.394s
user 0m0.004s 0m0.000s 0m0.394s
sys 0m0.048s 0m0.048s 0m0.028s
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.
release resizing lock in error case of IOC_RESIZEFS
Thanks Djalal <email@example.com> for pointing it out and his patch for
IOC_GROUP_EXTEND and IOC_GROUP_ADD.
rename __ext4_group_extend to ext4_group_extend_no_check.
initialize block bitmap of last group.
remove code initalizing inode bitmap and inode tables.
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html