Next steps for ext3dev/ext4?

Hi all,

Now that the dust has somewhat settled on the ext3/ext4 lkml thread, we
need to take stock and suggest next moves.

So where are we now?  One problem on that thread was that there were two
separate objections being closely linked:

      * Do we separate out new features into a visibly distinct
        filesystem in order to prevent forwards incompatibility
        problems? 

and

      * Do we separate out new code to prevent destabilising of the
        existing ext3 codebase?

These are quite distinct problems.  Compatibility is not a reason to
split the code, for example: we can easily teach e2fsprogs to register a
new "mke4fs" binary, and teach the kernel to register an "ext4"
filesystem with a different default feature set, without forking code at
all.

There seems to be a consensus around forking the code to preserve ext3
reliability, though.  That's fine.  I'm not sure we're ready for "ext4",
simply because of the compatibility concern: we don't yet have all of
the incompatible features that are on the roadmap (examples of other
work outstanding include adding new inode fields for subsecond-
granularity timestamps, larger max i_nlinks etc; lazy initialisation of
allocated data/inodes/bitmaps and others.)  So if we bump things to ext4
now, then users will *still* get bitten later on when we add those new
features.  For example, perhaps we can go with "ext3dev" or "ext4dev"
for now to make that explicit; "ext4" would work too as long as we
document the expectations clearly.

If we do split the code, though, it has to be done with an understanding
of the consequences.  So I think that the key questions remaining
include:

      * Are we willing to commit certain *compatible* upgrades, such as
        the multi-block allocation/delayed allocation performance
        patches, to ext3+ only, such that they will not be available to
        existing ext3 users without switching to the new codebase?

      * Do we split jbd while we're at it?  (The same arguments apply:
        there is even one incompatible jbd feature on the cards, journal
        checksums);

      * Do we need to retain backwards compatibility code in the new
        ext3+ codebase, so that existing users can choose to select new
        performance features without necessarily enabling feature
        incompatibilities?

My personal leaning for now would be to split both ext3 and jbd, but to
retain compatibility code in ext3+ for now to enable performance work to
go on in that branch without major compatibility implications. 

--Stephen



Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642