So, I'm running the ZFS beta seed on Mac OS X.
It's a beta, but in my opinion, beta in filesystems are solid. This isn't... yet. First off, I've had about 20 panicks in the last 8 hours of running it. Not good. This alone means it is alpha to me. The beta aspects of it don't bother me so much and I see its potential.
Basic setup
I resized my internal 160GB boo drive to 100 and 60. (60 being blank).
/usr/sbin/zpool create internal disk0s3
/usr/sbin/zfs create internal/homes
/usr/sbin/zfs create internal/homes/jesus
/usr/sbin/zfs create internal/homes/jesus/src
/usr/sbin/zfs create internal/homes/jesus/Documents
/usr/sbin/zfs create internal/homes/jesus/Library
rsync -av ~jesus/src/ /Volumes/internal/homes/jesus/src/
rsync -av ~jesus/Documents/ /Volumes/internal/homes/jesus/Documents/
rsync -av ~jesus/Library/ /Volumes/internal/homes/jesus/Library/
### [*** BOOM ***]
### (again and again and again -- sent many reports to Apple)
/usr/sbin/zfs destroy internal/homes/jesus/Library
rm -rf /Users/jesus/src
rm -rf /Users/jesus/Documents
/usr/sbin/zfs set mountpoint=/Users/jesus/src internal/homes/jesus/src
/usr/sbin/zfs set mountpoint=/Users/jesus/Documents internal/homes/jesus/Documents
Problems from the get-go
The zpool worked and the creation of the homes FS worked. The others created, but didn't mount. I had to run zfs mount manually to get them to work. Notably, on next reboot (after an import glitch) they all auto-mount fine.
The flurry of panicks during my attempts to sync my ~/Library/ was disappointing. No data loss occurred and no corruption happened. So, it was the "best kind" of panick (if there is such a thing). My src and Documents is about 9GB and that copied over without any issues. Anyway, it should be obvious that I backed everything up before I started.
Boot up / Shutdown
First, there is no bootup integration to see previously imported zpools. Also, when I try to import the zpool it thinks it is from a different system and I have to use -f... very odd. Anyway, my zpool is call "internal," so I create a StartupItems dir called ZFS and had it /usr/sbin/zpool import -f internal on boot and /usr/sbin/zpool export internal on shutdown. Of course, normally we wouldn't export the pool on shutdown, but as it thinks it is owned by someone else when I boot next, I thought it safer that way.
Backups
One of the reasons I wanted ZFS is that snapshot capabilities. In addition to snapshots proper, zfs send allows one to push a full (or incremental) snapshot to a stream. Zetaback is a sweet tool to do automatic network-based backups of ZFS volumes. It is very efficient and quite exploratory in nature. However, zfs send just produces: internal error: Bad file descriptor which means "unimlemented." A beta-ism -- at least it didn' panick.
Metadata
One of the shining points (arguably) of Mac OS X is Spotlight. And while you might not use Spotlight directly, you likely use it indirectly. Mac OS X manages these on a per-volume basis and something in ZFS confuses it substantially.
# mdutil -s /
/:
Indexing enabled.
# mdutil -s /Volumes/internal
/Volumes/internal:
Indexing enabled.
# mdutil -s /Volumes/internal/homes
/Volumes/internal/homes:
Indexing and searching disabled.
# mdutil -v -i on /Volumes/internal/homes
/Volumes/internal/homes:
Indexing and searching disabled.
As you can see, you cannot enable metadata indexing and searching on zfs filesystems within a pool. This (to me) sounds like a simple fix, but still it makes moving my Documents to ZFS unappealing.
Summary
I'm excited to see where this is going. I sure do like ZFS on Solaris. I'd like to see Mac OS X with tight integration. I don't care so much about the system disk being ZFS (though it would be nice), it's the user directories that could really make it shine.
Wednesday, October 31. 2007 at 12:38 (Link)
Doesn't posting this violate the ADC NDA? The ZFS rw kext isn't public.
Wednesday, October 31. 2007 at 18:01
I don't believe so; not my interpretation of it anyway. If they send me a note to take it down, I will -- the information in here isn't so revolutionary or disclosing.
ZFS is covered under the CDDL license, so by distributing it to anyone they are distributing the changeset therein.
I'm also not an ADC member, so I'm not sure how I'd be subject to an NDA. If anything it would be the EULA distributed with it, but I didn't see anything that would prevent this blog post.
Thursday, November 1. 2007 at 00:41
As an update, I misdiagnosed the brokenness of zfs send. It isn't unimplemented. It appears that somewhere in the code path that prevents zfs send from writing to the terminal, it also prevents it from writing over a pipe to another process. zetaback_agent uses this to do backups. I've patched it and committed the work-around so that on Mac OS X it does this work via a FIFO.
Which brings me to my next bug. mkfifo on ZFS will create a pipe, but it acts like a regular file -- writing to it does not block on a reader and the data remains after read. Luckily, zetaback runs from a root login and root's home directory isn't on ZFS, so the pipe it creates works like a charm.
When I plug my laptop in tomorrow, I'll learn if the hacks were fruitful.
Thursday, November 1. 2007 at 01:04
I accidentally delete Derek's follow-up to my follow-up. Turns out I am an ADC member, though I got the ZFS Public Preview from elsewhere. I can't find an NDA on their site and I know I don't have a signed/countersigned copy :-)
Regardless, the disk image I have is a Public Preview and nothing in the EULA restricts discussion.
I'm also pretty sure they modified ZFS source files to get it to compile and the CDDL requires providing the source for those changed files (couldn't fine them on www.opensource.apple.com). So, perhaps everyone is in the wrong. People need to relax about this stuff more.
Were ZFS a closed-source product, I could see more sensitivity. ZFS is open. It's incorporation into Mac OS X is awesome. And I'm really glad that it is a public preview, because filesystem *must* be stable and the only way to get there is via a wide test audience.
Saturday, November 10. 2007 at 14:34
The ZFS Beta has been public since the 26th when 10.5 was released.
Did you read apple's pdf regarding how to set up ZFS? if you label your disk correctly, for example;
diskutil partitiondisk /dev/disk2 GPTFormat ZFS %noformat% 100%
and then create your zpool using /dev/disk2s2 you wont have any trouble importing on boot and it will be automatic. You can get rid of your startupitem.
All of that is covered in the "zfs_readme_v1.1a.pdf" available for download by _anyone_ at developer.apple.com along with the _public_ zfs.kext
I've been using zfs for my home dir on my mac pro since the night of the 26th.
It panics a little but not as bad as you're describing, I did have a really bad time with it on my gen1 mbp. It would panic all the time. I had to give up trying to use it on there.
Thursday, January 10. 2008 at 18:20 (Link)
I'm also excited to see where this all is going and I would like to see system disk being ZFS definitely.
Saturday, February 9. 2008 at 13:18 (Link)
Hey,
I've figured out a zfs fifo trick for zfs as well, but for me the data doesn't really remain on the disk, at least not as far as I could tell. I basically did the following:
mkfifo zfs_send
ssh remotehost mkfifo zfs_recv
ssh remotehost "zfs receive target < zfs_recv"
cat zfs_send | ssh remotehost "cat > zfs_recv"
zfs send > zfs_send
This will basically use two fifo's to pipe your snapshot to the remotehost. Not very efficient, but quite much working. The order is important by the way.