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

my only concern is that ext4's going to get features yet to be designed,
coded and tested. so it's going to take quite long. I was hoping we
could get ext3+ which incorporates already implemented and tested things
like extents (delayed allocation probably). that could be a short-term
solution for those who need large fs support now/soon and it would be
forward compatible with nextgen ext4.

thanks, Alex

>>>>> Theodore Tso (TT) writes:

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

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

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

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

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

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

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

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

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

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

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

 TT> 4) At some point, probably in 6-9 months when we are satisified with
 TT> the set of features that have been added to fs/ext4, and confident as
 TT> to their reliability, we will submit a patch which causes the fs/ext4
 TT> code to register itself as the ext4 filesystem.  At that point, we may
 TT> also request that fs/ext3 be deleted and that fs/ext4 register itself
 TT> as supporting the ext3 filesystem as well.

 TT> Comments?

 TT> 							- Ted

 TT> Using Tomcat but need to do more? Need to support web services, security?
 TT> Get stuff done quickly with pre-integrated technology to make your job easier
 TT> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 TT> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
 TT> _______________________________________________
 TT> Ext2-devel mailing list
 TT> [email protected]
 TT> https://lists.sourceforge.net/lists/listinfo/ext2-devel

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