Ext4 is now the primary filesystem on my laptop

Over the weekend, I converted my laptop to use the ext4 filesystem.  So far so good!  So far I’ve found one bug as a result of my using ext4 in production (if delayed allocation is enabled, i_blocks doesn’t get updated until the block allocation takes place, so files can appear to have 0k blocksize right after they are created, which is confusing/unfortunate), but nothing super serious yet.  I will be doing backups a bit more frequently until I’m absolutely sure things are rock solid, though!

I am using the latest ext4 patches and the tip of the e2fsprogs git repository.  Hopefully when we get the bulk of the patches merged into the mainline kernel after the 2.6.26 ships and the 2.6.27 merge window opens, and after I ship out e2fsprogs 1.41 (I have one work-in-progress pre-release, with another coming soon), it’ll be ready for much more wide-spread testing.

In addition to the excellent crew of ext4 developers, I’d like to call out for special thanks Gary Howco and Holger Kiehl, two early users/benchmarkers of ext4 who tried our latest code, and reported bugs that had previously escaped attention by developers (who had been mostly testing the code via the same old test suites); their additional workloads and benchmarks flushed out a few additional bugs.   Thanks, guys!!

Hopefully after a few weeks of my using ext4 for real-live work, I’ll find a few last few bugs to be fixed, and/or feel much more confident it’s ready for me to recommend to others for their production data.

13 thoughts on “Ext4 is now the primary filesystem on my laptop

  1. How far along is online defrag? That’s the killer feature for me (and I’m guessing a number of other people). I’ve gotten into the habit of tarring up my home directory, deleting it, and then untarring every few months, which works, but is somewhat annoying to do.

  2. Btmorex,

    The on-line defrag patches are in the patch queue, but to be honest, I don’t think they have received much attention or testing by anyone other than the developers. With the delayed allocation and flex_bg features, I anticipate that ext4 should be better about fragmentation resistance than ext3, but I’ll definitely find out more about that as I use on my laptop.

    After the 2.6.27 merge, the only thing left on the kernel side that I know about that needs doing is (a) bug fixes/optimizations, (b) online resize if flex_bg is enabled (this is easy; it should be fixed before 2.6.27 is released), (c) background zero’ing of the unused inode table int he kernel so that “mke2fs -E lazy_itable_init=1” can be the default to significantly speed up mke2fs, and (d) review, cleanup and integration of the online defrag changes.

    Things like online defrag and the background itable init were lower priority items since they didn’t affect the on-disk format and they were isolated enough changes that people could be testing the main body of the ext4 code while we finished off those last bits.

  3. Omri,

    By production purposes you mean, “non-critical testing”, right? Ext4 is still definitely in shakedown stage, and while I appreciate people willing to serve as guinea pigs, I do get nervous when people get over-enthusiastic about using bleeding-edge code on production enterprise server machines! While getting feedback from enterprise server users/workloads is much appreciated, please don’t risk your data/business on ext4 just yet. 🙂

  4. i don’t quite understand why ext4 made it so quickly into the kernel, while some other solutions didn’t (specifically squashfs, which recently got merged or is still being planned to get merged, and of course that other famous filesystem starting with r 😉 ).

    how stable is ext4 as of now? i’d like to try it, but i’m not sure what are the risks right now.

  5. Indeed. By testing for production purposes I mean for the same purposes as the actual production setup, (run the same databases in the same way) but not as a candidate FS for the production setup. That’s long time away.

  6. Yoshi314,

    Ext4 went into the kernel early because it was designed and specified as an incremental set of improvements to ext3. Since ext3 was already in the kernel, it was already known to conform to kernel locking/coding requirements (well, the latter with some grandfather clause effect), and so we just forked the ext3 codebase to call it ext4. In fact you can mount ext3 filesystems with the ext4 code — it is that backwards compatible.

    As far as readiness, portions of the code (the extent and delayed allocation code) has been used in production in Luster (clusterfs’s product) for 2-3 years, and the core ext3 code is of course well-proven. How risky is it? Well, I am a bit nervous using it for my e-mail, source code, and home directory, but I am willing to risk my own data to it. As more people use it w/o problem, we’ll be more confident as to its stability, but it always starts with the core developers eating their own dogfood. 🙂

    Other filesystems that are starting from scratch do have it harder, because the barrier to entry is higher. There’s no denying that. Whether this is fair or not, I don’t set kernel policy; there are arguments about whether or not new device drivers (regardless of code quality) should be added to the kernel. I will note that if that adding subpar code quality device drivers is controversial, the case for subpar quality filesystems is much weaker, given that (a) if you have a certain hardware device, a new device driver is critical if you want to use it; where as we have plenty of functional filesystems, and the criticality of Yet Another Filesystem is much less, (b) a buggy device driver might lead to a crash, which can suck — but a buggy filesystem can lead to loss of user data, which sucks far more.

  7. Dear Theodore,

    I’m trying to get myself updated on ext4 development every now and then (as it scratches some of my personal filesystem itches) but I’m finding it very difficult to actually dig out any useful information.

    Googling things like “ext4 status” gives links to ages-old blogposts by apparently unrelated people; the ext4 wiki on kernel.org seems to be plain dead, and kernel ChangeLogs only show particular atomic changes of no real meaning to a non-involved person like me.

    Is there a website where this stuff, along with some timeline (and related kernel releases) is summed up? I too would like to serve as a guinea pig (within reason) as soon as I read somewhere that the stuff is ready for public testing.

    From what I gather from the comments here, you’ll have most everyday functionaly in when 2.6.27 is released and I suppose there’ll be no on-disk format changes anymore. Please correct me if I’m wrong, and please let me know if there *is* a sensible source of information on this subject that I have missed.

    Best regards,


  8. antoszka,

    You raise a good point. The documentation for ext4 could definitely be better, especially as far as web pages are concerned. The ext4 wiki on kernel.org is probably the most up-to-date, but it is pretty stagnant in places. We need some help in improving the wiki; maybe you can help?

    In any case, I’ve updated the getting started page here (at http://ext4.wiki.kernel.org/index.php/Ext4_Howto) so it should be correct and up to date. If you are willing to build your own kernel you can definitely start now. We’ll try to do a better job with the wiki moving forward!

    — Ted

  9. Hey Ted,

    Sorry for the off topic post, but if you could email username: Jaciss about his Google Gears comment on your Sony Reader post, that would be much appreciated.

    It’d be great for us non-developers to get Google Reader to sync up with the Sony Reader. Thanks,


Leave a Reply

Your email address will not be published. Required fields are marked *