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:
XFS | ext4 | |
---|---|---|
Block write (MB/s) | 54 | 51 |
Block rewrite (MB/s) | 23 | 24 |
Block read (MB/s) | 51 | 50 |
Sequential creates (/s) | 4470 | 17801 |
Runtime (minutes) | 23 | 22 |
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:
XFS | ext4 | ext4 + extents | |
---|---|---|---|
Block write (MB/s) | 54 | 51 | 68 |
Block rewrite (MB/s) | 23 | 24 | 30 |
Block read (MB/s) | 51 | 50 | 64 |
Sequential creates (/s) | 4470 | 17801 | Too fast |
Runtime (minutes) | 23 | 22 | 18 |
This looks fun.. 😉
Heh.
C’mon, compare ext3, you know you want to 🙂
And then ext3 mounted as ext4 and had extents/uninit_bg turned on fscked.
I’d have to shrink my fs, create a new ext4 one, transfer, shrink, grow, transfer quite a few times to get mine over to a fresh ext4 fs 🙁 Hopefully it’d end up just as quick as if I did a tune2fs && fsck
I was interested to read a couple of assessments of ext4, knowing that features like Extents (hello, ODS-1?) would work well… but I was quite staggered to see here just how well! (-: