Executive summary: ext4 rocks, check the numbers at the end!

With 2.6.28 arriving over Xmas I took the opportunity to upgrade my home desktop and laptop to it (the laptop had been running a number of RC releases quite happily). Everything was happy so I thought I’d try migrating my /home partition to ext4, but before I started I decided to run a quick Bonnie++ comparison between XFS and the new stable ext4 from the console before the rsync. The (very) rough numbers were:

I didn’t note down the rest. So not a lot of difference there (or so I thought, but more on that in a bit). Using rsync to copy all my data over didn’t take too long and a quick shuffle of UUID’s in /etc/fstab and I rebooted and was happily using my shiny new ext4 logical volume. Everything was working fine but it wasn’t until I was poking in the logs a day or two later that I noticed this:

EXT4-fs warning (device dm-13): ext4_fill_super: extents feature not enabled on this filesystem, use tune2fs.

That’s unusual because since 2.6.23 that was meant to be enabled by default. A quick play with tune2fs under both Ubuntu Hardy and Intrepid showed that they didn’t support that option so I ended up grabbing
e2fsprogs from SourceForge and building it myself. With that done I could use its mkfs.ext4 command to build a fully functional ext4 filesystem and get the far better message:

EXT4-fs: file extents enabled

Another long rsync later and I was up and running with ext4 with all the features I wanted.

Of course this meant that my initial ext4 numbers were without extents, so I’ve just done another run (though this time with X and a full KDE 4 session going) and was blown away by the results:

Version 1.03b       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
quad            16G           68123  17 30013   6           64239   8 363.1   1
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
quad,16G,,,68123,17,30013,6,,,64239,8,363.1,1,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++

real    18m18.005s
user    0m1.280s
sys     1m46.434s

That’s a full 2 minutes faster (and then some) and the I/O is just enormous!

So here’s that first table again, but with an extra column for ext4 with extents:

This looks fun.. 😉

I’ve been playing with my new work laptop, a Dell E4200 (which I chose as I wanted something light) and thought I’d run Bonnie++ on my XFS /home partition on the SSD (a “SAMSUNG SSD Thin uSATA 128GB M” according to dmesg) to see how it compares to spinning disk. Here’s the results with Ubuntu Intrepid (8.10):

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
sys26            2G           68551  27 38896  23           90404  30  1356   6
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16   556   8 +++++ +++   679   7   605   8 +++++ +++   442   5
sys26,2G,,,68551,27,38896,23,,,90404,30,1355.6,6,16,556,8,+++++,+++,679,7,605,8,+++++,+++,442,5

real    3m56.775s
user    0m0.580s
sys     0m36.930s

So comparing with some old results on my home desktop system seems to show that the block I/O numbers are better, but the file manipulation stuff is much worse! Once I can get btrfs on here I’ll have to try again. 😉

The graphics hardware in the Neo Freerunner (Glamo) is missing support for some of its 3D support, and so the OpenMoko folks are looking for developers who can help them out with this:

Having said that, if someone wants to seriously develop for the glamo, please get in touch with me and we will find a legally correct way to extend the smedia documentation to you.
In fact we have done that in a few cases before already, but I’m not sure how much actual codes have come out of that. I think very little 😉 So we need some really serious coders that don’t mind a tough challenge.

Looks like another person to contact might be Graeme Gregory:

Over the next few weeks I shall be working on Xglamo to bring it into the Xorg family of drivers. If people come up with interesting patches while I am working on this I can certainly give them a tryout.