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.

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].