From: Jeff Garzik <jeff@garzik.org>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Proposal and plan for ext2/3 future development work
Date: Thu, 29 Jun 2006 21:14:53 -0400 [thread overview]
Message-ID: <44A47B0D.7020308@garzik.org> (raw)
In-Reply-To: <E1Fvjsh-0008Uw-85@candygram.thunk.org>
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
next prev parent reply other threads:[~2006-06-30 1:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-28 23:55 Proposal and plan for ext2/3 future development work Theodore Ts'o
2006-06-30 1:14 ` Jeff Garzik [this message]
2006-06-30 1:59 ` Joel Becker
2006-06-30 17:13 ` Badari Pulavarty
2006-06-30 18:24 ` Joel Becker
2006-06-30 19:17 ` Steve Lord
2006-06-30 19:29 ` Badari Pulavarty
2006-06-30 10:39 ` Andi Kleen
2006-06-30 15:14 ` Theodore Tso
2006-07-01 9:42 ` Adrian Bunk
2006-07-01 10:29 ` Theodore Tso
2006-06-30 11:09 ` Patrick McFarland
2006-06-30 23:44 ` Mingming Cao
2006-07-24 13:04 ` Guillaume Chazarain
2006-07-24 18:11 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44A47B0D.7020308@garzik.org \
--to=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).