Re: [Ext2-devel] Re: [RFC] file extents for EXT3

From: Theodore Ts'o (tytso_at_mit.edu)
Date: 08/13/03

  • Next message: Stephen Rothwell: "[PATCH][DOCO] Re: 2.6.0-test3 and dnotify" 
    Date:	Wed, 13 Aug 2003 00:32:18 -0400
To: Jeff Garzik <jgarzik@pobox.com>

    On Mon, Aug 11, 2003 at 12:23:07PM -0400, Jeff Garzik wrote:
    >
    > The net effect of slowly sliding features into ext2/3 via feature flags
    > creates the poor situation we have today: your filesystem, and your
    > kernel, may or may not support the featureset you're looking for. Sure,
    > slowly sliding features into existing filesystems can be made to work
    > with compatibility flags and careful thought.
    >
    > However, I argue that there should be an ext2/3 filesystem feature
    > freeze. And in this regard I am talking about _software_ versions, not
    > filesystem formats. ext4 should be where the bulk of the new work goes.
    > Please -- leave ext3 alone! It's still being stabilized.

    Any time you add features to a filesystem, there will potentially be
    compatibility problems. In the case of htree, a lot of careful
    thought was put into how to add them without causing compatibility
    problems, and we succeeded.

    There are at least three separate issues here, that you're conflating
    into one.

    The first is code stability. If we add new features, we risk possibly
    destablizing the tree. However, I'm sure any instability will be no
    worse, and probably a lot better, than what people suffered when the
    IDE drivers went to hell and back. Kernel development survived, even
    if it was a bit inconvenienced. In addition, we are very careful
    about not modifying the old code paths when we add a new feature, even
    this risk can be minimized. (And of course, we would only do this in
    development kernels, and in initial test patches first!)

    The second is issue is one of filesystem backwards compatibility
    issues. I disagree that it is a "poor" situation that a kernel may
    not support a filesystem with new features. That's just simply life!
    Whether or not you use minor versions with feature flags, which might
    or might not have compatibility, issues, or you do an entirely new
    major number bump, the net result is still the same. For example,
    there's no hope at all of using a kernel that understands only
    reiserfs3 to mount a reiserfs4 filesystem.

    However, in some cases we can do better, by making certain changes
    which preserve read-only compatibility, or which only requires a
    forced update to a newer version of e2fsprogs. In the case of file
    extents, certainly we won't be able to do anything but an incompatible
    version bump. But this is true whether we do this via a filesystem
    compatibility flag or by changing the major number in the superblock!

    In any case, it will always be up to the user to decide whether or not
    to enable any new feature.

    > Of course, the other alternative is to rename ext3 to "linuxfs", add a
    > "no journal at all" mode, and remove ext2. But I prefer my "ext4"
    > solution :)

    I would like to add "no journal" support to ext3, and then rename it
    to ext2. At some level, the only reason why we called it ext3 was
    mainly for the code stability issue. (Well, that and in case people
    wanted a slightly smaller variant of ext2/3 --- but the people who
    care about size issues will likely be in embedded applications, and in
    those applications they will probably want to use something like jffs2
    anyway.)

    I really don't want to have to support n different variants of the
    ext2/3/4/5/6/7 codebase. That's just silly, and it's a code
    maintenance headache.

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

  • Next message: Stephen Rothwell: "[PATCH][DOCO] Re: 2.6.0-test3 and dnotify"

    Relevant Pages

    • Re: During FC1 to FC4 upgrade, Do I need to upgrade Ext3 file systems?
      ... SElinux may be ... Filesystem features: has_journal ext_attr ... I'd do the upgrade then worry about ...
      (Fedora)
    • Re: [RFC 0/13] extents and 48bit ext3
      ... problems related to progressive, stealth filesystem upgrades. ... Users are never given a clear indication of when their metadata is being upgraded, there is no clear "line of demarcation" they cross, when they start using extents. ... Since there is no user-visible fs upgrade event, users do not have a clear picture of what features are being used -- which means they are kept in the dark about which kernels are OK to use on their data. ... duplicating features would be to merge the fs/extto fs/ext, then make fs/ext register itself as a filesystem under "ext2", "ext3", and "ext4". ...
      (Linux-Kernel)
    • Re: Cant used parted to resize recent ext2 partitions, what has changed?
      ... Build current ext2 utils and use tune2fs to check which features are enabled ... Filesystem volume name: ... disabling features on filesystem with live data can potentially ... possible because feature may affect data layout and you can't change data ...
      (linux.redhat)
    • Re: Cant used parted to resize recent ext2 partitions, what has changed?
      ... Build current ext2 utils and use tune2fs to check which features are enabled ... Filesystem volume name: ... disabling features on filesystem with live data can potentially ... possible because feature may affect data layout and you can't change data ...
      (comp.os.linux.setup)
    • Re: Proposal and plan for ext2/3 future development work
      ... the filesystem format is still changing. ... features are being added that might not be supported on older ... older kernels (just as in theory all of the kernel code that we are ... reason why we have to break that compatibility promise. ...
      (Linux-Kernel)