Re: [Ext2-devel] [RFC 0/13] extents and 48bit ext3

[Jeff Garzik]

Andreas Dilger wrote:
> On Jun 09, 2006  21:09 -0400, Jeff Garzik wrote:
> > Theodore Tso wrote:
> > > Jeff, you seem to think that the fact that the layout isn't precisely
> > > the same after an on-line resizing is proof of something horrible, but
> > > it isn't.  The exact location of filesystem metadata has never been
> > > fixed, not in the past ten years of ext2/3 history, and this is not a
> > > big deal.  It certainly isn't "proof" of on-line resizing being
> > > something horrible, as you keep trying to claim, without any arguments
> > > other than, "The layout is different!".  
> > No, I was proving merely that it is _different_.  And the values where 
> > you see a _difference_ are the ones of which are no longer sized 
> > optimally, after you grow the fs to a larger size.
>
> It sounds like you don't know what you are talking about, which is OK,
> except that you keep harping on some non-existent point.
>
> > So you incur a performance penalty for resizing to size S2, rather than 
> > mke2fs'ing the new blkdev at size S2.  Certainly within the confines of 
> > ext3 that cannot be helped, but a different inode allocation strategy 
> > could improve upon that.
>
> ???  Can you please be specific in what the performance penalty is, and
> what specifically is "not sized optimally" after a resize?  How exactly
> does inode allocation strategy relate to anything at all to online resizing.

Inodes per group / inode blocks per group, as I've already stated.

	Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/