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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
