Apparently Tens Complement, the company that was developing ZFS for Mac OS X as a separate product has been acquired by Green Bytes in mid 2012. They've very kindly made a version available to everyone for free. There's no UI or any other frills, but for those already familiar with ZFS from Solaris, this is a good development.

See http://zevo.getgreenbytes.com/ for more details.

You have to register on their forums first, before you can download the new ZEVO Community Edition

I know it's hardly news, but after the announcements at WWDC in June, it's apparent that Apple's upcoming Mac OS version 10.6 aka "Snow Leopard" won't have ZFS like everyone thought it would.

And with MacZFS stuck at build 119 and with still some potentially serious problems, I've kind of put my plans for any sort of major Mac ZFS setup on the backburner. Maybe 10.7? Who knows.

I guess the Drobo is looking better and better these days.

Creating ZFS Mirrors

• Simple 2-way mirror
• Detach drive from mirror
• Attach drive to mirror
• Make a 3-way (or n-way) mirror
• Growing usable space in a mirror

Since we're focusing on redundant and protected storage, we're going to jump right in and talk about ZFS mirrors. We'll cover normal ZFS striping and concatenated storage shortly though.

The easy way to practice using ZFS is to use files as our virtual devices (vdevs). Normally vdevs are usually entire hard drives or large slices of them. But vdevs be just about anything, including files. For production purposes you'd never use files as vdevs, since they're layered on top of your operating system and subject to some performance overhead. Besides your vdevs would also be at the mercy of things that goes on in your file system (e.g.

Avoid Prompts for the Admin Password when Writing to ZFS volumes

When you're creating zpools and ZFS volumes you have to be doing it with root privileges, so naturally any volume you create is going to be owned by root. So if you are trying to write to these volumes as your normal Mac login, it's going to prompt for the admin password every time.

The easy fix is just to make yourself the owner of that volume:

# chown -R UserName:GroupName /Volumes/myzpool

If you have multiple users, then use chmod to allow access to other users.

Empty Trash won't work

If you delete files on a ZFS volume via the Finder, you won't be able to use Empty Trash properly. The files don't show up in the Finder anymore, but they're actually just moved to a hidden directory called ".Trashes". You have to use "rm" in the Terminal to really remove the file (or just "rm -rf .Trashes").

As far as most things go, this is not a huge deal, but you could easily forget that this issue exists and accidentally let your zpool fill up over time and then waste a bunch of time troubleshooting it. Maybe some sort of Applescript/Automator/cronjob approach would provide a semi-seamless workaround.

Mac ZFS Kernel Panic Crashing

First up is the more egregious behavior that I've seen so far with Mac ZFS. As I've been experimenting, I've noticed that it fails in the most ungraceful way possible (kernel panic and immediate Grey Screen of Death) when any of these conditions occur:

• You're using an external USB/FW drive for ZFS and you unplug the drive before you unmount any ZFS volumes and "zfs export -f poolname" the ZFS pool on that external drive.
• If a vdev/drive in a zpool has a failure that will put you into a FAULTED state. So on a RAIDZ (single-parity) if you lose 2 drives, that causes the kernel panic. Or on a RAIDZ2 (double-parity), if you lose 3 drives, same deal. Or in a 2-way mirror if you lose both halves of the mirror.
• Drive went to sleep or got spun down (like on a laptop or if you have the spin-down set in your Energy Saver settings).

Apparently ZFS panics (literally!) when there are an asynchronous writes that already returned "success" and would make disk state inconsistent. The supposed reason for defaulting to panics is "maintaining data integrity" because "ZFS cannot guarantee that the information in the cache, ZIL, and media will be consistent." [original post].