On Jun 27, 2008 16:36 +0200, Fr�d�ric Boh� wrote: > Le jeudi 26 juin 2008 à 17:26 -0600, Andreas Dilger a écrit : > > On Jun 26, 2008 16:58 +0200, Fr�d�ric Boh� wrote: > > > From: Frederic Bohe <frederic.bohe@xxxxxxxx> > > > + num_meta_group_infos_max = num_meta_group_infos + > > > + le16_to_cpu(es->s_reserved_gdt_blocks); > > > > The only drawback of NOT handling this properly is that once (eventually) > > we allow resizing with META_BG this code will be broken again. It at > > least deserves a comment like "Need to handle this properly when META_BG > > resizing is allowed" so that it will show up on any grep for META_BG. > > > > It probably also makes sense to round this up to the next power-of-two > > value, since kmalloc will do that internally anyways, and it gives us > > some resizing headroom for no cost. > > Do you have any idea of how this headroom could be used in the future ? For e.g. resize with META_BG, which does not need new reserved blocks to be added. Since the space is already allocated because of kmalloc use of 2^n slab size, we may as well make it "available" even if it isn't used. 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
