The Musings of Chris Samuel

After the previous benchmark of btrfs I thought it’d be interesting to revisit ZFS using FUSE under Linux, so after updating to the current tip (02d648b1676c) in the Mercurial trunk I created a 30GB LVM volume for testing and gave it a go. Now you can’t compare it to previous results as this is completely different hardware, but the numbers look quite respectable in comparison to the in-kernel file systems tested yesterday.

Continue Reading »

In July I was commissioned to write an article for LinuxWorld called “Emerging Linux Filesystems” which they published in early September in three parts. Part of the deal was that there was a 90 day exclusivity period for them before I could republish it elsewhere, which has now lapsed.

So you can now read the article in its original (single page) form complete with inline images and graphs and covering Ext4, NILFS, btrfs, Reiser4, ChunkFS and ZFS under both FUSE on Linux and OpenSolaris. Enjoy!

My thanks to Don Marti of LinuxWorld for commissioning (and paying for) the article and to Dragan Dimitrovici of Xenon Systems for the loan of the test system!

Recently LinuxWorld commissioned me to write an article on Emerging Linux Filesystems (the formatting is a bit different from the original I sent, but the slideshow of graphs now works) and have kindly given me permission to present a talk based on my work at the October Linux Users of Victoria (LUV) meeting.

So if you can make it you can hear about my experiences with ChunkFS, btrfs, NILFS, ext4, Reiser4 and ZFS/FUSE, as well as with ZFS under OpenSolaris (in this case Nexenta).

I’d also like to thank Dragan at Xenon Systems for the loan of a shiny, Linux friendly, test system!

An email interview with myself following on from my ZFS/FUSE blogs has formed part of an article about ZFS/FUSE on LinuxWorld, which has also been noted on LWN.

I was wondering whether FUSE was being a bottleneck in my various ZFS-FUSE tests or whether the performance issues at present are just that ZFS is very young code on Linux and that the fact that Riccardo hasn’t yet started on optimisation.

Continue Reading »

Here’s a quick update on my previous results for striping and RAID-Z when testing ZFS on an old system with multiple SCSI drives (see the previous post for details of the system config).

Continue Reading »

Having upgraded to the Feisty beta I thought it would be fun to see what (if any) affect it had on filesystem performance (especially given my previous aide memoir).

For these tests I stuck to my 3 favourites, JFS (from IBM), XFS (from SGI) and ZFS (from Sun, ported to Linux using FUSE by Ricardo Correia due to Sun’s GPL-incompatible license). This is a follow on from a slew of earlier ZFS & XFS benchmarking I did reported on previously¹.

Summary: for Bonnie++ JFS is fastest, XFS next fastest and ZFS slowest and Feisty made XFS and ZFS go faster (didn’t record my previous JFS results sadly).

The fact that ZFS is slowest of the three is not surprising as the Linux FUSE port hasn’t yet been optimised (Ricardo is concentrating on just getting it running) and is also hampered by running in user space. That said it still manages a respectable speed on this hardware and does have useful functionality that makes it useful to me.

Continue Reading »

1. here, here, here and here [back]

I’m a bit behind at the moment, but this is something worth a mention.

Ricardo Correia’s port of Sun’s ZFS (which I’ve been playing with for a while) has finally reached its first beta release!

He’s made some useful performance improvements recently as well as tidying up some of the memory handling and fixing various bugs, including that bug from the upstream that yours truly got bitten by.

Here’s an updated Bonnie++ run for comparison.

Version  1.03       ------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
inside           2G           18838   5  6995   2           18277   2 144.4   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  2795   5  9658   9  3462   5  2739   5 13736  11  4015   6
inside,2G,,,18838,5,6995,2,,,18277,2,144.4,0,16,2795,5,9658,9,3462,5,2739,5,13736,11,4015,6

real    10m12.258s
user    0m0.840s
sys     0m18.605s

Compared to previous results the write speed has improved, but the read speed seems to have dropped off a bit. Still, it’s early days yet.

Those who know me in my day job know that I’m pretty good at breaking things, so I guess I shouldn’t be surprised I found a ZFS bug that was from the OpenSolaris code base and had been sitting there for about a year unnoticed. The ZFS on Linux developer has now fixed the bug and sent a patch back upstream, so hopefully there will be a fix in OpenSolaris because of work done on Linux!

The good thing is that because I found it on Linux running ZFS using FUSE the bug didn’t take my system down when the ZFS file system daemon died. http://www.csamuel.org/2007/06/19/zfsfuse-makes-it-to-linuxworld-and-lwn/

Linus added support for block device based filesystems into 2.6.20, so it’ll be interesting to see what (if any) effect on ZFS/FUSE it will have, especially given it’s named in the commit.

I never intended this, but people started using fuse to implement block device based “real” filesystems (ntfs-3g, zfs).

Looks like Ubuntu’s Feisty Fawn will ship with this as the 2.6.20 kernels in the development versions have the fuseblk filesystem showing up in /proc/filesystems once you’ve loaded the fuse module, and the fuse-utils package seems to support it too.

Update: Sadly it appears that this isn’t much use for ZFS.