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

[Theodore Tso]

On Fri, Jun 09, 2006 at 10:11:59PM -0400, Jeff Garzik wrote:
> Trivial to prove false, by your statement above if nothing else.  But 
> anyway:
> Run mke2fs on a blkdev of size 500MB, and one of 500GB.  Note values.
> Now resize blkdev formatted for size 500MB to 500GB, and note differences.

OK, so *that's* what you were trying to get at.  I wish you had said
that from the first, since most people who are creating filesystems to
resize (i.e., on LVM or RAID systems), don't start them as small as
500MB.

Yes, the default inode ratio and blocksize is different for
filesystems under 512MB.  But that's largely irrelevant for the use
cases of online resizing, where people will generally be starting with
a filesystem *far* larger than 512megs.  They might starting with an
LVM sized to be 2 gigs and resize it to 5 gigs.  Or 100 gigs and
resizing it 200 gigs; or 500gigs; or a terrabyte.  In all of those
cases, the results are identical.

It also by the way has nothing to do with the "inode allocation
algorithm", as you caleimd.  The biggest difference will come from the
use of a 1k blocksize instead of 4k blocksize, but that's a matter of
the defaults that were selected for "small" filesystems.  If someone
was creating a file system that they knew they were likely to resize
to 500GB, they could always create it with an explicitly specified
blocksize of 4k, and also specify a different inode ratio.

And this is your argument that on-line resizing is a horrible hack,
and ext3 should be thrown out and rewritten from scratch?  That's
weak.   


One other thought --- people do *care* about backwards compatibility
from a filesystem format level, and they do appreciate being able to
easily upgrade and take advantage of new filesystem features without
needing to do a dump/restore.  

If you don't care about compatibility, but want a scalable filesystem,
take a look at JFS.  It's very, very, good at what it does (and has
support for extents and large block numbers) --- and it's smaller than
XFS and doesn't have the VNODE and System V/IRIX API compatibility
crud of XFS.  The only downside with it is that you do have to do a
backup, reformat, and restore, and of course, the lack of support from
pretty much all of the major distributions.

						- Ted
-
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/