ZFS On Linux With Ubuntu 12.04 LTS

[phoronix]

Phoronix: ZFS On Linux With Ubuntu 12.04 LTS

It has been a while since last benchmarking the ZFS file-system under Linux, but here's some benchmarks of the well-known Solaris file-system on Ubuntu 12.04 LTS and compared to EXT4 and Btrfs when using both a hard drive and solid-state drive.

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

[uid313]

I just wish Oracle changed the license of ZFS to a more liberal one or dual licensed it or something.

[hartz]

It is not the CDDL that restricts license type mixing, it is the GPL (as evidenced by the fact that a: everything in the linux kernel must be GPL, and b: ZFS under CDDL is already included with the BSD kernel and Mac OSX.)

I wish Linus could change the linux kernel to be under a more liberal license. But alas I believe even if he wanted to, he couldn't because, as far as I understand it, he would have to get permission from all people who have ever contributed anything to the Linux kernel.

[hartz]

Michael, after my last complaints about how you test ZFS you did not change one single thing!?

ZFS perform middle of the road in these tests, and I agree that with ZFS not being part of the main line kernel that would and should be a stopper for most people. But for those who want the features.... the parts that only ZFS offers... You didn't demonstrate any of those.

ZFS realy shines when it has enough memory and lots of hard drives.... Driving a Grand Prix F1 car on a cross-country rally road will simply not allow it to show it's real performance capability. In fact my mother's Renault 5 will outrun it after the first bump higher than an inch!

So how about a system with 8 drives spread over multiple controllers and busses to pit the systems against? Add ZIL log and ARC cache devices. Report on the actual observed bottlenecks (eg for File System X it was the disk busy time, for File System Z it was CPU, etc) This is important because one user will need CPU cycles spare to run his workload, another will have more demand on I/Os per second. The same result could mean different things to different people depending on their requirements.

I find the suspicious tone of your un-answered questions scoff-worthy. If you doubt a test result, perform a test to check and confirm the validity of the first test result; monitor the disk statistics - did the disk actually write all the data, is the system still clearing caches after the test completed, etc.

Honestly, you are one of very few sites that actually monitor and test Solaris-derived technologies and report on these, which shows a level of maturity. But that brings with it responsibility for correct testing and reporting. I am frustrated that Phoronix, one of the few sites that report on Solaris/BSD/ZFS etc, DOESN'T DO IT RIGHT!

[Michael]

So how about a system with 8 drives spread over multiple controllers and busses to pit the systems against? Add ZIL log and ARC cache devices. Report on the actual observed bottlenecks (eg for File System X it was the disk busy time, for File System Z it was CPU, etc) This is important because one user will need CPU cycles spare to run his workload, another will have more demand on I/Os per second. The same result could mean different things to different people depending on their requirements.

Not enough enterprise storage hardware/resources for more extensive disk testing, besides not being a key focus/interest of Phoronix to justify additional time and expense. This was just some brief ZFS testing I did after someone made a decent PayPal tip a few days ago and asked for some updated ZFS benchmarks.

[disi]

Not enough enterprise storage hardware/resources for more extensive disk testing, besides not being a key focus/interest of Phoronix to justify additional time and expense. This was just some brief ZFS testing I did after someone made a decent PayPal tip a few days ago and asked for some updated ZFS benchmarks.

Is there a link on openbenchmark.org where people can compare their results?

//edit: nevermind http://openbenchmarking.org/result/1...SU-ZFSLINUXB51

[johnc]

Michael, after my last complaints about how you test ZFS you did not change one single thing!?

ZFS perform middle of the road in these tests, and I agree that with ZFS not being part of the main line kernel that would and should be a stopper for most people. But for those who want the features.... the parts that only ZFS offers... You didn't demonstrate any of those.

ZFS realy shines when it has enough memory and lots of hard drives.... Driving a Grand Prix F1 car on a cross-country rally road will simply not allow it to show it's real performance capability. In fact my mother's Renault 5 will outrun it after the first bump higher than an inch!

So how about a system with 8 drives spread over multiple controllers and busses to pit the systems against? Add ZIL log and ARC cache devices. Report on the actual observed bottlenecks (eg for File System X it was the disk busy time, for File System Z it was CPU, etc) This is important because one user will need CPU cycles spare to run his workload, another will have more demand on I/Os per second. The same result could mean different things to different people depending on their requirements.

I find the suspicious tone of your un-answered questions scoff-worthy. If you doubt a test result, perform a test to check and confirm the validity of the first test result; monitor the disk statistics - did the disk actually write all the data, is the system still clearing caches after the test completed, etc.

Honestly, you are one of very few sites that actually monitor and test Solaris-derived technologies and report on these, which shows a level of maturity. But that brings with it responsibility for correct testing and reporting. I am frustrated that Phoronix, one of the few sites that report on Solaris/BSD/ZFS etc, DOESN'T DO IT RIGHT!

The way I see it... people who know of ZFS and want to use it, will know how to set it up properly.

And those who don't know how to set up ZFS have no business using it.

So in the end it's of little consequence IMO.

I would love to build my home file server around Linux... but this is one area where Linux is sub-par. Maybe some day with Btrfs. Maybe some day.

[liam]

The way I see it... people who know of ZFS and want to use it, will know how to set it up properly.

And those who don't know how to set up ZFS have no business using it.

So in the end it's of little consequence IMO.

I would love to build my home file server around Linux... but this is one area where Linux is sub-par. Maybe some day with Btrfs. Maybe some day.

Have you heard of SnapRaid? It's pretty similar to FlexRaid (and I think UnRaid, though I'm uncertain) in that each disk has an independent file system. Spanning is accomplished with Greyhole or mhddfs. The code scales amazingly well and offers up to double redundancy (the developer, who is very engaging and active, is working on triple redundancy). Also, it detects bit rot (using the murmur hash, IIRC).
The downside is that it isn't realtime (cron based snap-shoting), so it is best used for data that doesn't change often. You also don't get the read improvements from striping, but you do get the benefit of not having to worry about losing the whole array.

[TeoLinuX]

I think that more than pure performance, what makes ZFS so interesting (to justify the many attempts to port it on Linux) are its features. Same goes for BTRFS
So, benchmarking one single disk box in a generic desktop install has no much meaning.
Well ok, the meaning is that you can see the performance level for that particular config, but you don't get the point, which is the very advanced features of ZFS and BTRFS.

It's like testing a Ferrari sportscar vs a old VW Golf driving both of them in a busy supermarket parking lot. You would end up saying that Ferrari is clumsy with no much handling. Simply it's not its battlefield.

There's a reason why every OS devoted to run a datacenter or a NAS is willing to use ZFS...
That said, I'm perfectly fine with ETX4 on my smartphone and in my Linux Boxes. And I run a NAS box with ZFS in raidz

[TeoLinuX]

Both posts by Hartz above: +1