On Thu, Aug 28, 2008 at 04:38:00PM +0200, Frédéric Bohé wrote:
> with flexbg :
> It works the same way but this time, meta-datas blocks for new groups
> are created inside the working filesystem (in a group containing
> meta-datas for the whole flex group). resize2fs scans from the end of
> the last flex_group meta-datas until it finds enough space to put the
> new meta-datas. This is not a problem when resizing offline, but when
> online, the blocks found for the meta-datas may be allocated by someone
> else before the GROUP_ADD ioctl occurs.
Yep, that's a problem. Probably the quick fix is to allocate the
metadata outside of the working filesystem at least for now. Because
we're extending the filesystem block group by block group, the
quick-and-dirty fix would be to just use the non-flex_bg allocation
algorithm and allocate the block bitmap, inode bitmap, and inode table
in the block group.
This we can do in the userspace code right now, since the kernel code
is enforcing that the block and inode bitmaps be in the new block
group at the moment anyway. It is highly undesirable, since it would
break the advantage of flex_bg, but at least online resizing would
work.
To fix it right, I suspect we will need a new ioctl and do more of the
work inside the kernel, instead of in userspace. That's the only way
we can do the block allocation inside the kernel efficiently.
- Ted
--
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
