login
Search
Theodore Ts'o posted an update on the ext4 filesystem [story], "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 - 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
Hah! And this comes from one of the most open Reiser4 critics!
Wasn't (and isn't!) Theodore's argument, whenever Reiser4 crops up, that Reiser4 is bad, that its development was too far away from lkml? That reviews were only asked for when the patch was so huge to literally ensure that it's not going to happen?
And now, ext4 goes down _exactly_ the same route. Plus, we can expect inferiour performance compared to Reiser4, given the fact that ext4 is being brought to you by the same bunch of people who brought you ext3, which is still a crawling snail compared to Reiser3.
This is not meant as a troll comment, but rather in the same style as Theodore's comments. So don't blame me. Blame Theodore.
Fortunately it's that much more reliable
Not too many people complain about losing data to ext2 or ext3.. Seems like it's status quo with the Reiser filesystems.
Agreed. Speed doesn't need
Agreed. Speed doesn't need to come at the expense of reliability. I have never lost a byte of data on ext3. Reiser is nowhere near as stable. This isn't a fanboy speaking either, this is someone who has actually used both filesystems extensively and has come to a conclusion founded in reality.
It is getting reviewed
You seem to have missed teh part where the patches _are_ getting reviewed. They are being reviewed to make sure that they meet the upstream patch critirea. Hans _never_ attempted that, he just threw what _Hans_ felt was right upstream and then bitched that no one wanted to review it. Stuff that is pre-vetted by one of the kernel devs ( Theo being one) before it is pushed upstream, while make it lot easier for the upstream review process to happen faster.
Long block support?
With IDEMA releasing the new long block data support standard (moving hard drive blocks from 512 bytes to 4096), are there yet plans to support this with EXT4 or another Linux filesystem, please?
See http://www.idema.org for details.
David Neeley
Dallas
dbneeley@gmail.com
No change is needed
Most file systems already use 4kb blocks or bigger, so there's no extra support needed. You just have to be careful in laying out the partitions, so that you don't get unaligned ios which will hurt your performance a lot.
ext4 for NAND ?
The (near) future, on laptops at least, will be flash memory as hard drives. AFAIK this introduce a new set of limitations (max 1000000 write operations per cell, etc) that todays hard drives don't have.
Will ext4 be developed with that in mind or will it be optimised for servers and datacentres?
And if not, what fs will I use on my laptop in 2009? JFFS2? YAFFS2? Or good ol' ext3?
Re: ext4 for NAND ?
The (near) future, on laptops at least, will be flash memory as hard drives. AFAIK this introduce a new set of limitations (max 1000000 write operations per cell, etc) that todays hard drives don't have.
This is a nominal rating, the actual average number of cycles before failure is likely much higher. However, the thing that saves the day is, flash normally fails on erase. So when that happens, the failed part of the flash gets mapped as a bad area and life goes on without it. Filesystems like JFFS(2) are designed to skip around these bad areas, and for generic filesystem an additional level of indirection is provided in the block driver (or in the upcoming generation of hybrid disks, in the disk drive hardware) to remap all accesses, once again skipping around bad areas. So the flash isn't dead until a high proportion of it has failed, which is going to take a long, long time.
Now, how nice it would be if someone eager for fame took it upon themselves to test some (properly remappable) flash to destruction, in order to give us some good empirical numbers that don't come from a flash vendor.
Any one looked at NILFS?
http://www.nilfs.org
It's looking like it could end up being a nice desktop filesystem before too long.