linux-ext4 - Re: Online resize with flex bg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Aug 2008 13:11:56 -0400
From:	Theodore Tso <tytso@....edu>
To:	Frédéric Bohé <frederic.bohe@...l.net>
Cc:	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: Online resize with flex bg

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