Sadly I suspect this 10 year old test box tops out at 256MB, and I believe there is still RAM free whilst it is running. Bonnie is a fairly severe test case, it tries to ensure that the system can’t get clever about using RAM to cache, so what other people are testing may not be purely the filesystem (and disk) performance.

As Riccardo has mentioned elsewhere he’s still got a lot of work to do on performance under FUSE, and my guess is that this is one of them!

ZFS performance comes at the very drastic expense of CPU power. The nice trade off is that it appears to scale well above other file systems can do, using massive amounts of CPU, but delivering unheard of performance.

If you have the CPU usage metrics, please post back.

-=dave

Time to turn that box back on and dist-upgrade to the new release!

As for the Mac, I’ve no idea how you could go about that I’m afraid..

I’ve been trying to work out how to get ZFS going on my Mac. The next OS ( 10.5 “Leopard”) will have it, but they’re delaying that, and I have about 2TB of disks lying around in random configurations/partitions. If only I can get a virtual machine to access the disks directly, I could then export the shares via NFS and use them from my main OS.

Your message got labelled as spam by Akismet and fortunately I just spotted it now as I was about to kill off everything it had found!

Anyway, your comment on the sdb, sdc, sdd, and sde being slices of the same physical disk isn’t true for Linux, ‘sd’ refers to a SCSI disk device and then each drive is allocated a letter after that. Then if I was partitioning the drives I would get sdb1, sdb2, etc to refer to each partition.

So just sdb, sdc refers to the entire (unpartitioned) drive.

Hope that helps!

The slowest part of most disk IO is the actual physical disk and the hard disk head, which moves in concentric circles around the spindle of the disk. The speed that the disk rotates, and the speed that the head seeks to a new location is important here.

When you use a striped arrangement, as in ZFS’s raidz1 – you are taking advantage of the fact that several disk heads are reading and writing your data for you. So the computer can divide up a read request between several disks, and get rid of the physical bottleneck by getting different heads to read (or write) different slices.

I notice that you are using sdb, sdc, sdd, and see – which are partitions (or slices) of the same physical disk. This means that striping won’t work – since there’s only one physical disk head involved in reading this data. All you’re really doing with ZFS here is combining several partitions into one easily accessible pool. There should be no performance benefit, and in fact it should be slower, since the same data has to be written to several parts of the same disk by the one head.

SO – if you want faster ZFS and striping, use several physical disks. In fact, if you want a more reliable/resilient setup, don’t mirror several partitions from the same disk together either – since the one disk is likely to stop working thereby killing all your mirrors at once. Instead use several actual disks, ideally several physical controllers too.

Or have I missed something here?

–
Shameless plug: Free Travel Advice and Blog at BallOfDirt.com

As for “just for fun”, well it was his baby so he can do what he pleases, the best bit is that even if he gets eaten by a killer penguin at Canberra zoo (again) others will be able to carry on with it, it no longer relies entirely on him (though it would not be a painful transition!). Where I work we run large clusters for scientific HPC and they all depend on Linux.

I dunno about Solaris being “more advanced”, the kernel has some interesting bits (ZFS mainly) but it’s still a System V derivative and will have a heap of legacy code in it, not to mention kernel interfaces they can’t break easily, whereas Linux doesn’t have those sorts of constraints and they actively don’t want stable kernel interfaces so they can keep improving it. Of course where the kernel gets exposed to user space is a different matter…

I spent a long time sysadmining lots of commercial Unix variants (including SunOS and Solaris) and always one of the first things I did with them was install bash and various GNU utilities to make life bearable!

However, now Nexenta exists with a GNU userspace, that makes it much more interesting to use, it’s just a shame that the Solaris kernel is too bloated to boot on my test machine.