raattgift wrote:The finder eject button only sends an unmount volume command except in cases of removable media, to which it sends an eject; it's not very smart with regard to multiple vfs filesystems sharing the same underlying storage.
The zfs vfs happily unmounts datasets for the Finder, but the only way to remove a pool gracefully is via the command line (zpool export poolname).
You almost certainly don't want the Finder eject button (or a drag to trash) to do a pool export, as that will unmount every volume on the pool.
Arguably ZFS as a whole might benefit from the system exporting a pool when the last dataset is unmounted, but I don't think there would be universal agreement on that, and I also don't think that the ZEVO port should depart from the others on that point without a lot of thinking about future support burden and so on.
Removing devices when a zpool is still imported (even when no datasets are mounted) is treated as a device fault, which will degrade or fault a pool depending on the vdev the device was part of. In most cases when devices are reattached, ZFS will automatically DTRT. This was tested heavily at Sun over the years. However, with arbitrary privileged code that reaches around behind the vfs layer's back to talk to the individual devices, one can only make guesses about what could happen.
…
FWIW, I rarely use the finder eject button (and even more rarely drag-to-trash) in general anyway; I typically have lots of Terminal and iTerm windows open (sometimes xterm too) and/or am logged in via ssh. I also make use of CoreStorage, SoftRaid, and ZFS simultaneously on a couple of systems, and the Apple GUI apps tend to suffer or cause confusion. (Also FWIW, I still have yet to navigate into a .zfs/snapshot directory with the Finder rather than using the CLI to do read-only stuff (mainly cp/rsync/less) old data).
On the other hand, I think there is broad agreement that zfs should adopt the Mac look-and-feel as much as possible, and so feedback from enthusiasts/early-adopters tripping over problems when using typical Mac GUI tools is likely useful.
Finally, this particular problem is architectural. Here's the starting message a lonnnnnnnng thread from 2009 on exactly the topic of unmounting vs exporting. The tl;dr version is, "this has been in TFM for years (prior to 2009), nobody's submitted a compelling change request or open source code patch, and while this is safe to do for enterprise disks, consumer disks, enclosures, bridge chipsets, etc, can do things that have not been the focus of battle testing".
http://mail.opensolaris.org/pipermail/z ... 26087.html
Interesting!
I realised, long ago, that export could be done from the command line.
I assumed that eject/unmount of all file systems from a pool is followed by export.
I assumed that with ZEVO Community Edition 1.1.1 the export is dynamic, because:
- import is dynamic (unavoidable with 1.1.1; see disable automatic zpool import)
- I often saw export notifications (from HardwareGrowler)
– and I thought that those notifications appeared more often than my use of zpool export … commands.
My memory is not mistaken. From ZEVO QuickStart Guide.pdf for Silver Edition 1.0:
Ten’s Complement LLC wrote:If you have Growl notifications enabled (see notifications section), you will see a “pool exported” message each time a ZEVO volume is unmounted.