Re: [PATCH v2] ext4: fix initialization of UNINIT bitmap blocks

[Andreas Dilger <adilger@sun.com>]

On Sep 24, 2008  12:23 -0400, Theodore Ts'o wrote:
> > Do you mean that making ext4_group_info generic for both mballoc and
> > oldalloc will reduce the code complexity ?
> 
> Long-term, we want to do this, yes.  There's a lot of stuff in mballoc
> that we probably need to move out into generic code.  I'll sending
> patches shortly that move the /proc handling code into the generic
> code, and also saving 2k of compiled object code in the process.
> 
> Here, I think main argument is since mballoc is on by default, and the
> benefits of this are huge, is that we would save memory by using an
> unused bit in ext4_group_info.

Exactly.

> A related question is at what point should we remove the oldalloc code
> altogehter?

I'd vote for sooner rather than later.  We're pretty clear on the mballoc
benefits, and there is a lot of old/duplicate cruft that is confusing
(e.g. old block reservation code) that could be removed at the same time.

> > Anyway, I don't understand why we should write bitmaps to disk after
> > that, and why we should zeroing the inode table.  Don't we end up with a
> > fast mkfs and a slow mount doing all the stuff older mkfs was doing ?
> > The UNINIT feature would become less interesting.
> 
> It would be an absolute disaster to do this at mount time, especially
> if it included zeroing the inode table.  Zeroing the inode table must
> be done in a background kernel thread,

Yes, definitely I meant "in a background thread that can be interrupted
if there is other fs activity or unmount", not synchronously with the
mount.  The risk of fatal itable/GDT corruption in the first minute of
using a newly formatted filesystem is small, and the corresponding value
of any data in that filesystem would be equally small.

> with appropriate locks to avoid races with the block allocation code

Definitely...

> I don't think we should worry about initializing the bitmaps in
> advance.  There's just no advantage in doing that for the bitmaps.

Well, just some small safety that there isn't complete garbage on
disk, which helps e2fsck make a better decision in case of old data
still on the disk.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.