On Wed, Sep 24, 2008 at 02:57:28PM +0200, Frédéric Bohé wrote: > > You are right ext4_group_info structure was not as big as I thought. > 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. A related question is at what point should we remove the oldalloc code altogehter? > > Also, if you are considering this approach (to initialize the in-memory > > bitmaps at mount time) they should be written to disk even if unused. > > Please also consider doing the inode table zeroing at the same time. > > This would allow uninit_bg to avoid doing it at mke2fs time. > > In fact, I was not considering doing this at mount time, but it could be > a good approach. > 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, with appropriate locks to avoid races with the block allocation code (this is one of the places where eliminating the old allocation code would make life easier). I don't think we should worry about initializing the bitmaps in advance. There's just no advantage in doing that for the bitmaps. For the inode table we want to do this for safety's sake, but that's not a concern for the bitmaps. - 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
