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. -- 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
