Re: [zfs-macos] booting with minimal HFS+ and maximal ZFS (startup/shutdown scripts)
Daniel Bethe
my non-GPT-enabled zpool. Like I said before, I can start it up via the
official launchd fashion.
Hossenfeffer:~ dtm$ cat /Library/LaunchDaemons/com.bandlem.mac.zfs.fs.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.bandlem.mac.zfs.fs</string>
<key>ProgramArguments</key>
<array>
<string>zpool</string>
<string>import</string>
<string>-a</string>
<string>-f</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StandardOutPath</key>
<string>/private/var/log/maczfs.log</string>
</dict>
</plist>
I took out the '-d /dev' from there, if you don't want it
scanning every drive for a zpool, because ZFS will have cached the relevant
pool
data in /etc/zfs. But I do need '-f' because the shutdown process is
unreliable!
Now I have the shutdown script. *sigh* Here it is, newly created by me (such
as it is) and
executed by launchd according to the old ways since epoch:
Hossenfeffer:~ dtm$ cat /etc/rc.shutdown.local
#!/bin/bash
LOG=/var/log/maczfs.log
date >> $LOG 2>&1
echo "umounting ZFS" >> $LOG
zfs umount -a >> $LOG 2>&1
echo "Exporting all ZFS pools" >> $LOG
for i in $(zpool list -H -o name) ; do
zpool export $i >> $LOG 2>&1
done
Don't forget how paranoid launchd is, and do this:
sudo chown 0:0 /etc/rc.shutdown.local
sudo chmod u+x /etc/rc.shutdown.local
I have rebooted 10 or 20 times today just to test this procedure. Just to test
this shutdown script, I issued a scrub prior to shutdown, to ensure that the
zpool would be as busy and slow as possible upon shutdown. Shutdown took extra
long, and the log says that the ZFS umount attempt failed.
Whatever! It's a kludge! But underneath lies ZFS, so what's the worst that
could happen?! It's not like we're going to lose any data, huh?
I'm posting these so as to insult and offend someone's sensibilities enough that
they fix it properly as per Mac OS's best practices! Because I don't know how!
Daniel Bethe
'diskutil umount' is, at this point.
So I changed it to this:
Hossenfeffer:~ dtm$ cat /etc/rc.shutdown.local
#!/bin/bash
# ZFS shutdown script by dtm and KonaB1end
LOG=/var/log/maczfs.log
echo -n "ZFS shutdown " ; date >> $LOG 2>&1
echo "umounting ZFS" >> $LOG
#zfs umount -a >> $LOG 2>&1
for i in $(zfs list -H -t filesystem -o mountpoint) ; do
diskutil umount $i >> $LOG 2>&1
Alex Blewitt
> Actually, we're finding that 'zfs umount -a' is apparently less reliable than
> 'diskutil umount' is, at this point.
Probably spotlight. Because spotlight has a hold on the drive, but expects DiskUtil to tell it that a device is going (and it conflates device/filesystem) then there can be conditions in which the filesystem doesn't get unmounted (because ZFS things that someone's using it) and so you can be hung at that point. If you unmount -f then it ignores any people in use and doesn't suffer that problem.
Alex
Daniel Bethe
> Probably spotlight. Because spotlight has a hold on the drive, but expects
>DiskUtil to tell it that a device is going (and it conflates device/filesystem)
>then there can be conditions in which the filesystem doesn't get unmounted
>(because ZFS things that someone's using it) and so you can be hung at that
>point. If you unmount -f then it ignores any people in use and doesn't suffer
>that problem.
That's a fair guess, but I disabled spotlight on ZFS using 'mdutil -i off
/Volume/....'
Hossenfeffer:~ dtm$ mdutil -vas
/Volumes/big:
Indexing disabled.
/:
Indexing enabled.
Scan base time: 2011-03-25 10:36:49 -0500 (2777 seconds ago), reasoning: 'scan
not required - avoided catchup scan'
KonaB1end says that it's because not all of Apple's improvements from 10a286
were ported to MacZFS. He says it uses the disk arbitration framework which
ours doesn't use. I'm not a programmer, so I can't verify or expound upon that.
But I can show you my repeated experiences....
Hossenfeffer:~ dtm$ zpool export big
cannot unmount '/Volumes/big': Operation not permitted
Hossenfeffer:~ dtm$ zpool export big
cannot unmount '/Volumes/big': Operation not permitted
Hossenfeffer:~ dtm$ zpool export big
cannot unmount '/Volumes/big': Operation not permitted
Hossenfeffer:~ dtm$ zpool export big
cannot unmount '/Volumes/big': Operation not permitted
Hossenfeffer:~ dtm$ zpool export big
cannot unmount '/Volumes/big': Operation not permitted
Hossenfeffer:~ dtm$ zfs umount big
cannot unmount '/Volumes/big': Operation not permitted
Hossenfeffer:~ dtm$ zfs umount big
cannot unmount '/Volumes/big': Operation not permitted
Hossenfeffer:~ dtm$ zfs umount big
cannot unmount '/Volumes/big': Operation not permitted
Hossenfeffer:~ dtm$ diskutil umount /Volumes/big
Unmount successful for /Volumes/big
Hossenfeffer:~ dtm$ zfs mount -a
Hossenfeffer:~ dtm$ zpool export big
Hossenfeffer:~ dtm$ sudo zpool import big
Hossenfeffer:~ dtm$ zpool export big
cannot unmount '/Volumes/big': Operation not permitted
Hossenfeffer:~ dtm$ zfs umount big
cannot unmount '/Volumes/big': Operation not permitted
Hossenfeffer:~ dtm$ zfs umount big
cannot unmount '/Volumes/big': Operation not permitted
Hossenfeffer:~ dtm$ zfs umount big
cannot unmount '/Volumes/big': Operation not permitted
Hossenfeffer:~ dtm$ diskutil umount /Volumes/big
Unmount successful for /Volumes/big
Hossenfeffer:~ dtm$
Alex Blewitt
> KonaB1end says that it's because not all of Apple's improvements from 10a286
> were ported to MacZFS. He says it uses the disk arbitration framework which
> ours doesn't use. I'm not a programmer, so I can't verify or expound upon that.
This is correct. I don't think the disk arb stuff was ever in the source that they shipped though as it would have likely been under ASPL and not CDDL.
Alex