Theodore Ts'o posted an update on the ext4 filesystem [story [1]], "I've respun the ext4 development patchset, with Amit's updated fallocate patches. I've added Dave's patch to add ia64 support to the fallocate system call, but *not* the XFS fallocate support patches. (Probably better for them to live in an xfs tree, where they can more easily tested and updated.) Yes, we haven't reached complete closure on the fallocate system call calling convention, but it's enough for us to get more testing in -mm." Jeff Garzik noted that none of this development was happening in the kernel as originally planned, "why isn't this stuff going upstream rapidly? AFAICT nothing much at all has happened upstream besides a mass renaming? The whole point of having ext4 in the kernel is to do development upstream, in the public view, getting new stuff in ASAP (even if that means changing or pulling some stuff later)."
Theodore acknowledged, "in general, yes, ext4 development has been a little slow; part of the problem is that we have a lot of people, but a number of folks are new and their patches need review before they are ready for upstream acceptance, and a number of other folks who should be doing the review have been overloaded with multiple other projects and have been time-sharing." He went on to note, "but we also get flamed when the patches don't meet various criteria, up to and including breaking on ia64. We are in the process of setting up automated testing to help address that problem, but it's a taken a little while to get that going. I'm also trying to schedule more time so I can do the needed review of the patches so they meet basic upstream standards so we *can* push them. If other folks would like to help with the review process, that would be more than welcome. But yes, we will try to get more of the patches pushed sooner rather than later."
From: Theodore Ts'o [email blocked] To: linux-ext4 Subject: 2.6.21-ext4-1 Date: Mon, 30 Apr 2007 11:14:57 -0400 I've respun the ext4 development patchset, with Amit's updated fallocate patches. I've added Dave's patch to add ia64 support to the fallocate system call, but *not* the XFS fallocate support patches. (Probably better for them to live in an xfs tree, where they can more easily tested and updated.) Yes, we haven't reached complete closure on the fallocate system call calling convention, but it's enough for us to get more testing in -mm. Also added Johann's jbd2-stats-through-procfs patches; it provides useful help in turning the size of the journal, which will be useful in benchmarking efforts. In addition, Alex Tomas's patch to free just-allocated patches when there is an error inserting the extent into the extent tree has also been included. The patches have been compile-tested on x86, and compile/run-tested on x86/UML. Would appreciate reports about testing on other platforms. Thanks, - Ted P.S. One bug which I've noted --- if there is a failure due to disk filling up, running e2fsck on the filesystem will show that the i_blocks fields on the inodes where there was a failure to allocate disk blocks are left incorrect. I'm guessing this is a bug in the delayed allocation patches. Alex, when you have a moment, could you take a look? Thanks!!
From: Theodore Tso [email blocked] Subject: Re: 2.6.21-ext4-1 Date: Mon, 30 Apr 2007 11:58:56 -0400 Sorry, I forgot to include the URL's where ext4 development patchset can be found: ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/ext4-patches/2.6.21-ext4-1 [2] - Ted
From: Jeff Garzik [email blocked] Subject: Re: 2.6.21-ext4-1 Date: Mon, 30 Apr 2007 13:16:19 -0400 Theodore Ts'o wrote: > I've respun the ext4 development patchset, with Amit's updated fallocate > patches. I've added Dave's patch to add ia64 support to the fallocate > system call, but *not* the XFS fallocate support patches. (Probably > better for them to live in an xfs tree, where they can more easily > tested and updated.) Yes, we haven't reached complete closure on the > fallocate system call calling convention, but it's enough for us to get > more testing in -mm. > > Also added Johann's jbd2-stats-through-procfs patches; it provides > useful help in turning the size of the journal, which will be useful in > benchmarking efforts. In addition, Alex Tomas's patch to free > just-allocated patches when there is an error inserting the extent into > the extent tree has also been included. > > The patches have been compile-tested on x86, and compile/run-tested on > x86/UML. Would appreciate reports about testing on other platforms. Why isn't this stuff going upstream rapidly? AFAICT nothing much at all has happened upstream besides a mass renaming? The whole point of having ext4 in the kernel is to do development upstream, in the public view, getting new stuff in ASAP (even if that means changing or pulling some stuff later). As it stands now, ext4 in the upstream tree is completely useless -- it's the same as ext3, and has been for months (since Oct 11). Hello? Upstream development? Ever heard of it? Jeff
From: Theodore Tso [email blocked] Subject: Re: 2.6.21-ext4-1 Date: Mon, 30 Apr 2007 13:45:30 -0400 On Mon, Apr 30, 2007 at 01:16:19PM -0400, Jeff Garzik wrote: > Why isn't this stuff going upstream rapidly? Some of the patches are ready to be pushed upstream, and that will be happening shortly. In the case of the fallocate patches, the system call interface hadn't been completely closed, so we don't want to push it until we have closure and consensus. The previous versions of the patches used an ioctl interface that would have gotten potshots from the all-ioctls-are-evil camp, and it was clear that a unified system call interface was the right thing. So we wanted to make sure the XFS folks were happy with the interface as well before we pushed it. In general, yes, ext4 development has been a little slow; part of the problem is that we have a lot of people, but a number of folks are new and their patches need review before they are ready for upstream acceptance, and a number of other folks who should be doing the review have been overloaded with multiple other projects and have been time-sharing. > The whole point of having ext4 in the kernel is to do development > upstream, in the public view, getting new stuff in ASAP (even if that > means changing or pulling some stuff later). That's true, but we also get flamed when the patches don't meet various criteria, up to and including breaking on ia64. We are in the process of setting up automated testing to help address that problem, but it's a taken a little while to get that going. I'm also trying to schedule more time so I can do the needed review of the patches so they meet basic upstream standards so we *can* push them. If other folks would like to help with the review process, that would be more than welcome. But yes, we will try to get more of the patches pushed sooner rather than later. Point taken. - Ted
Related Links:
- Archive of above thread [3]