Hi,
On Fri, 2006-06-09 at 11:08 -0400, Jeff Garzik wrote:
> Stuffing more and more features into fs/ext3 means you are following the
> path that leads to reiser4... where EVERYTHING under the hood is
> mutable, all within fs/ext3.
> Why do you insist upon calling the end result ext3, when the truth is
> that you are slowing rewriting ext3?
The trouble is, does it make sense to do otherwise?
Should large file support have resulted in ext4? ACLs/xattrs, ext5?
Htree, ext6? Online resize, ext7? Yes, let's make it ext8 for extents!
> Here's a key question for ext3 developers, which I bet has no answer:
> when is it enough?
When is the Linux syscall interface enough? When should we just bump it
and cut out all the compatibility interfaces?
No, we don't; we let people configure certain obsolete bits out (a.out
support etc), but we keep it in the tree despite the indirection cost to
maintain multiple interfaces etc.
> > While this is partly true, one of the big benefits is that you can
> > transparently upgrade your system to use the new features and improve
> > performance without a long outage window. Having a completely separate
>
> Changing the name to ext4 doesn't erase this capability.
The name is irrelevant here. FWIW, something we've considered is to
make the user visibility of a batch of new features more obvious by
labelling them "ext4", so "mke4fs" would automatically enable those
features and the filesystem could register "ext4" as an fs type in the
kernel.
But that could be done without forking the codebase. It would just be a
matter of binding feature flag sets to the given name. What you're
talking about is forking the codebase itself, and I don't see the need
for that right now.
> > ext4 filesystem doesn't improve the compatibility story at all. There
> > has been renewed discussion on implementing "mounting ext3 without a
> > journal", just for a recovery mode, because ext2 will not be modified
> > to get all of these features (running e2fsck on a huge filesystem each
> > reboot would be insane).
>
> So now you are going backwards, and implementing ext2-within-ext3?
No, it would be a readonly emergency mode, not writable ext2 at all.
> Are you ready to admit, yet, that ext3 is 100% mutable in the minds of
> ext3 developers?
The kernel syscall interface is 100% mutable by the same criteria.
Except in each case it's not "mutable", it's "extensible", which is a
*far* different thing.
> If all the ext3 developers are on board, that just implies that there is
> no clear definition of what "ext3" really means. With this patch
> series, and with future plans described here and elsewhere, the name
> "ext3" will become more and more meaningless.
Does the continuing addition of futexes, inotify, $FAVOURITE_FEATURE_OF_
THE_DAY mean that "Linux" is more and more meaningless? I fail to see
much difference. An application coded for linux-2.0's public interfaces
will, for the most part, if we do our jobs right, continue to work on
2.6. An application coded for 2.6, expecting to use AIO, large files,
futexes and NPTL, will definitely not run on 2.0. The incremental
extension of ext3 doesn't seem to be a fundamentally different concept.
Backwards compatibility of the kernel ABI is considered important; so in
ext3, the developers have a high regard for backwards compatibility of
on-disk data. Personally I see that as an asset, not a problem; indeed,
it was the single most important design criterion from the outset.
--Stephen
-
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]
