lkml.org 
[lkml]   [2006]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Ext2-devel] [RFC 0/13] extents and 48bit ext3
    On Sat, Jun 10, 2006 at 01:02:26PM -0700, Linus Torvalds wrote:
    > Starting from scratch - even if you literally start from the same
    > code-base - and allowing the old functionality to remain undisturbed is
    > just a very nice model. Yeah, yeah, it has some diskspace cost (although
    > at least from a git perspective, even that isn't really true), but we've
    > seen both in drivers and in filesystems how splitting things up has been a
    > great thing to do.
    >
    > Sometimes it's a great thing just because five years later, it turns out
    > that nobody even uses the legacy thing, and you decide to at that point
    > just remove the driver (or filesystem, but so far it's never been the
    > case for filesystems even if smbfs is a potential victim of this in the
    > not _too_ distant future), because the new version simply does everything
    > better.

    So you you would be in OK of a model where we copy fs/ext3 to
    "fs/ext4", and do development there which would merged rapidly into
    mainline so that people who want to participate in testing can use
    ext3dev, while people who want stability can use ext3 --- and at some
    point, we remove the old ext3 entirely and let fs/ext4 register itself
    as both the ext3 and ext4 filesystem, and at some point in the future,
    remove the ext3 name entirely?

    If that allows us to make forward progress and stop the
    flamewar, I'm willing to go along with it --- although e2fsprogs will
    continue to support ext2/3/4, and ext4 will have backwards
    compatibility support for ext3 formats (we can look at better ways of
    refactoring code to make it cleaner, if people don't like the current
    conditions). There are some real advantages to the system, especially
    if we can get changed merged into mainline for ext4 more quickly while
    it is under development and declared to be unstable (we can put it
    under CONFIG_EXPERIMENTAL if people really want).

    As far as people who want to use ext3 as the beginning point
    to do something that is has no forwards- compatibility, there's
    nothing stopping them from creating a jgarzikfs if they want. But I
    think I can speak for most of the ext3 development community that we
    feel that one of the strengths of ext2/3 is its ability to do smooth
    upgrades (and in many cases, downgrades as well, when people need to
    migrate a filesystem so it can be mounted on older kernels), and that
    it's one of the reasons why ext3 has been more succesful, than say,
    JFS.

    I do think there is plenty of room for competition, and I'm
    certainly looking forward to the brainstorming at next week's
    filesystem workshop. But ext2/3 has been pretty successful for over
    ten years given a certain development model and philosophy, and I for
    one am interested how much farther we can take it. Remember when
    academics were saying that Linux was an obsolete design and
    Microkernels was where it's at? If we had given up 15 years ago when
    Prof. Tennenbaum had said it, where would we be?

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

    \
     
     \ /
      Last update: 2006-06-10 23:29    [W:2.786 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site