Benchmarks Of ZFS-FUSE On Linux Against EXT4, Btrfs

[phoronix]

Phoronix: Benchmarks Of ZFS-FUSE On Linux Against EXT4, Btrfs

Last week we reported that a native ZFS implementation for Linux is soon being released that is based upon the work by Lawrence Livermore National Laboratory to bring Sun's ZFS file-system to Linux as a CDDL-licensed kernel module. As said though in that article, there is already a ZFS module for FUSE (File-system in User-space) that is already available and with it not living in the GPL-land of the Linux kernel, it is legally allowed, but it does not come without some performance overhead. Over the weekend though there's been some discussions in the related forum thread and elsewhere about the dependability of ZFS-FUSE and what the level of impact on using FUSE really amounts to in real-world usage. We have tested the ZFS-FUSE -- both the latest stable and Git snapshots -- and have compared this alternate ZFS Linux implementation to that of the native EXT4 and Btrfs.

http://www.phoronix.com/vr.php?view=15235

[Zhick]

On he first page, below the picture, the article says "KQ Infotech, the company working on a native ZFS module based upon the code of the Lawrence Livermore National Laboratory, has referred to ZFS as "crap."" I'm fairly sure you meant they were reffering to ZFS-Fuse as crap, not zfs itself.

[Michael]

On he first page, below the picture, the article says "KQ Infotech, the company working on a native ZFS module based upon the code of the Lawrence Livermore National Laboratory, has referred to ZFS as "crap."" I'm fairly sure you meant they were reffering to ZFS-Fuse as crap, not zfs itself.

Typo, yeah, meant FUSE. Fixed. Thanks.

[andrnils]

While interesting to see how the different FSes performs, there is so much more to it than speed, imho.

Like the fact that ext4 will loose your data ( it has done, no one will trust it for another 5 years ). And btrfs is still a bit raw, but has potential. Still needs a few years worth of enterprise usage to be considered trustworthy.

It's amazing that linux has so many filesystems to choose from, but not one really good choise

How about this test for a more "real world" example:

Given /some/dir to be backed up at regular intervals, how much work is involved to do that for the different FSes? To spicy things up, the backup has to be of the state of that dir at exactly 1pm.

[aakef]

Did you use "-o big_writes" for zfs-fuse? Also, GlusterFS recommends to use a patched fuse version, that increases max IO from 128kiB to 1 MiB.
See http://www.gluster.com/community/doc...php/User_Guide in the section Fuse.

Thanks,
Bernd

[smitty3268]

Given /some/dir to be backed up at regular intervals, how much work is involved to do that for the different FSes?

It's virtually zero work for both BTRFS and ZFS, because they are both COW filesystems. Obviously for other filesystems it's much more work.

[waucka]

It's virtually zero work for both BTRFS and ZFS, because they are both COW filesystems. Obviously for other filesystems it's much more work.

Snapshots only help you recover from "oops, I accidentally deleted a file", not "uh oh, the hard disk just failed".

[stan]

BTRFS sucks, and now that it's biggest pusher (Oracle) stopped caring about Linux, I seriously doubt it will ever get better. In fact, Oracle has an incentive to hurt BTRFS and Linux because they're a free alternative (and in direct competition) to their proprietary and revenue-generating Solaris.

One example it can hurt BTRFS is by not allowing it to be licensed GPL3+ and thus usable in the Grub2 bootloader.

[andrnils]

Snapshots only help you recover from "oops, I accidentally deleted a file", not "uh oh, the hard disk just failed".

True enough, but the requirement to make a backup of /some/dir at an exact time means for zfs and btrfs ( and any other fs which has snapshots ) that use use one command to get the snapshot, and at least for zfs just one other to copy the snapshot to a tape or whatever device floats your boat.

With extX and the rest, getting a backup at a specific time would mean that the fs would have to be remounted read-only for the duration of a tar or some such. Which in many production environments is a no-go.

At the end, was that 15% increase in some synthetic benchmark worth it?

And for those who wants to throw lvm into the picture to get snapshosts: it is not part of the FSes, so that is another discussion.

[edogawaconan]

who the heck use zfs or btrfs for server work with one disk and no redundancy?