lkml.org 
[lkml]   [2006]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Proposal and plan for ext2/3 future development work
    Theodore Ts'o wrote:
    > To address these issues, after discussing the matter amongst ourselves,
    > the ext2/3 developers would like to propose the following path forward.

    Overall... ACK from me. Thanks for listening.


    > 2) Bug fixes to fix 32-bit cleanliness issues, security/oops problems
    > will go into fs/ext3, but all new development work will go into fs/ext4.
    > There is some question about whether relatively low risk features such
    > as slimming the extX in-core memory structure, and delayed allocation
    > for ext3, which have no format impacts, should go into fs/ext3, or
    > whether such enhancement should only benefit fs/ext4 users. This is a
    > cost/benefit tradeoff for which the guidance of the LKML community about
    > whether the loss in code stability is worth the improvements to current
    > ext3 users, given the existence of the development branch.

    Agreed overall, though specifically for delayed allocation I think
    that's an ext4 thing:

    * First off, I'm a big fan of delalloc, and (like extents) definitely
    want to see the feature implemented
    * Delayed allocation, properly done, requires careful interaction with
    VM writeback (memory pressure or normal writeout), and may require some
    minor changes to generic code in fs/* and mm/*
    * Delayed allocation changes I/O ordering, and may require some retuning
    for workloads to remain optimal
    * Delayed allocation changes data layout on disk. HOPEFULLY for the
    better, but we won't know that until its been hammered a bit in the field.

    So while I agree it has no format impacts, I also think it has a
    non-trivial -- and currently unknown -- impact on stable systems.

    Also for the reasons listed, I think ext4 would be a far superior
    testbed for delalloc.


    > In addition, we are assuming that various "low risk" changes that do
    > involve format changes, such as support for higher resolution
    > timestamps, will _not_ get integrated into the fs/ext3 codebase, and
    > that people who want these features will have to use the
    > stable/development fs/ext4 codebase.

    ACK


    > 3) The ext4 code base will continue to mount older ext3 filesystems,
    > as this is necessary to ensure a future smooth upgrade path from ext3
    > to ext4 users. In addition, once a feature is added to the ext3dev
    > filesystem, a huge amount of effort will be made to provide continuing
    > support for the filesystem format enhancements going forward, just as
    > we do with the syscall ABI. (Emergencies might happen if we make a
    > major mistake and paint ourselves into a corner; but just as with
    > changes to the kernel/userspace ABI, if there is some question about
    > whether or not a particular filesystem format can be supported going
    > forward indefinitely, we will not push changes into the mainline
    > kernel until we are can be confident on this point.)

    ACK


    > 4) At some point, probably in 6-9 months when we are satisified with the
    > set of features that have been added to fs/ext4, and confident that the
    > filesystem format has stablized, we will submit a patch which causes the
    > fs/ext4 code to register itself as the ext4 filesystem. The
    > implementation may still require some shakedown before we are all
    > confident that it is as stable as ext3 is today. At that point, perhaps
    > 12-18 months out, we may request that the code in fs/ext3/*.c be deleted
    > and that fs/ext4 register itself as supporting the ext3 filesystem as
    > well.

    I continue to have a concern that it will become tougher over time to
    support all these features in the same codebase... so consider this a
    reluctant "ACK" for this last paragraph. :)

    Jeff


    -
    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-30 03:17    [W:0.026 / U:59.440 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site