- Code: Select all
14026366 com.apple.launchd 1 0x7fe019d04540.anonymous.umount 0 Conceived
14026372 com.apple.launchd 1 0x7fe019d04540.anonymous.umount 22351 This process showed up to the party while all the guests were leaving. Odds are that it will have a miserable time.
Near the tail of the log, filtered:
- Code: Select all
270013851 com.apple.launchd 1 0x7fe019d04540.anonymous.umount 22351 PID is still valid
271188316 com.apple.launchd 1 0x7fe019d04540.anonymous.umount 22351 Dispatching kevent callback.
271188320 com.apple.launchd 1 0x7fe019d04540.anonymous.umount 22351 EVFILT_PROC event for job.
271188323 com.apple.launchd 1 0x7fe019d04540.anonymous.umount 22351 Reaping
271188332 com.apple.launchd 1 0x7fe019d04540.anonymous.umount 0 Removed
That particular shut down did take an extraordinarily long time, and when I next started the system there was mount point debris (unsurprising, given the miserable party).
Usually: before shut down I take time, with Finder, to ensure eject of all external disks used by ZEVO.
Exceptionally: for the troublesome incident outlined above, I didn't bother to take that time with Finder. I left four external disks connected (three ZFS, one JHFS+), with their volumes mounted, when I requested the shut down.
At http://www.wuala.com/grahamperrin/publi ... de=gallery the first screenshot shows the file system hierarchy before the attempted shutdown.
Thoughts
Sometimes with child file systems, the order of eject/unmount is not ideal. Most noticeable in response to an Option-click on the eject icon for the parent.
For example, with the following file system hierarchy –
- Code: Select all
macbookpro08-centrim:~ gjp22$ zfs list | grep tall
tall 1.76Ti 26.0Gi 440Gi /Volumes/tall
tall/backups 889Gi 26.0Gi 10.9Gi /Volumes/tall/backups
tall/backups/LaCie d2 Extreme 1.73Mi 26.0Gi 648Ki /Volumes/tall/backups/LaCie d2 Extreme
tall/backups/LaCie d2 Extreme/11G 572Ki 26.0Gi 572Ki /Volumes/tall/backups/LaCie d2 Extreme/11G
tall/backups/LaCie d2 Extreme/12A 556Ki 26.0Gi 556Ki /Volumes/tall/backups/LaCie d2 Extreme/12A
tall/backups/blocky 3.31Gi 26.0Gi 3.31Gi /Volumes/tall/backups/blocky
tall/backups/gjp22 359Gi 26.0Gi 296Gi /Volumes/tall/backups/gjp22
tall/backups/zhandy 516Gi 26.0Gi 398Gi /Volumes/tall/backups/zhandy
tall/backups/zhandy/Pocket Time Machine 52.8Gi 26.0Gi 52.8Gi /Volumes/tall/backups/zhandy/Pocket Time Machine
– following an Option-click on the eject icon for tall, a child of tall/backups is sometimes not unmounted in good time.
(Maybe off-topic: lsof usually reveals that mds has files open on the affected file system(s). YMMV.)
Rarely
Following a timeout, or series of timeouts, the operating system continues to present an eject dialogue for a volume long after the volume was truly ejected. Below, a partial frame from the close of a movie (a screen recording) that will feature in a different topic …
An issue with diskarbitrationd and/or UnmountAssistantAgent.app? I wonder …
----
Impact
For me personally, the general issue – peculiarities at eject/unmount time – is rarely a bother. I simply wait for the OS to end its use of the file systems, then eject all before attempting a shut down.