Re: Agenda for ext3 developer interlock call (June 21th, 2006, 8:00PCT)

Proposal for ext2/3 future development work
===========================================

On last week's ext2/3 developer's conference call, I took an action
item to write up a summary of the proposal we had discussed.  Once we
gain consensus on the ext2-devel, we will submit it to LKML to see if
there are any objections with the path that we have planned.

Given the recent discussion on LKML, it is clear that many people feel
they have a stake in the future development plans of the ext2/ext3
filesystem, as it one of the most popular and commonly used
filesystems, particular amongst the kernel development community.  For
this reason, the stakes are higher than it would be for other
filesystems.  The concerns that were expressed can be summarized in
the following points:

	* Stability.  There is a concern that while we are adding new
		features, bugs might cause developers to lose work.
		This is particularly a concern given that 2.6 is a
		"stable" kernel series, but traditionally ext2/3
		developers have been very careful even during
		development series since kernel developers tend to get
		cranky when all of their filesystems get trashed.

	* Compatibility confusion.  While the ext2/3 superblock does
		have a very flexible and powerful system for
		indicating forwards and backwards compatibility, the
		possibility of user confusion has caused concern by
		some, to the point where there has been one proposal
		to deliberately break forwards compatibility in order
		to remove possible confusion about backwards
		compatibility.  This seems to be going too far,
		although we do need to warn against kernel and
		distribution-level code from blindly upgrading users'
		filesystems and removing the ability for those
		filesystems to be mounted on older systems without an
		explicit user approval step, preferably with tools
		that allow for easy upgrading and downgrading.

	* Code complexity.  There is a concern that unless the code is
		properly factored, that it may become difficult to
		read due to a lot of conditionals to support older
		filesystem formats.

Unfortunately, these various concerns were sometimes mixed together in
the discussion two months ago, and so it was hard to make progress.
Linus's concern seems to have been primarily the first point, with
perhaps a minor consideration of the 3rd.  Others dwelled very heavily
on the second point.

To address these issues, the ext2/3 developers would like to propose
the following path forward.

1) The creation of a new filesystem codebase in the 2.6 kernel tree in
/usr/src/linux/fs/ext4 that will initially register itself as the
"ext3dev" filesystem.  This will be explicitly marked as an
CONFIG_EXPERIMENTAL filesystem, and will in affect be a "development
fork" of ext3.  A similar split of the fs/jbd will be made in order to
support 64-bit jbd, which will be used by fs/ext4 and future versions
of ocfs2.

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.

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.)

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 as
to their reliability, we will submit a patch which causes the fs/ext4
code to register itself as the ext4 filesystem.  At that point, we may
also request that fs/ext3 be deleted and that fs/ext4 register itself
as supporting the ext3 filesystem as well.

Comments?

							- Ted

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