[OmniOS-discuss] How do non-rpool ZFS filesystems get mounted?

Chris Siebenmann cks at cs.toronto.edu
Tue Mar 4 23:42:40 UTC 2014


| You mention 'directories' being empty. Does /fs3-test-02 contain empty
| directories before being mounted?

 It doesn't. All of /fs3-test-01, /fs3-test-02, /h/281, and /h/999
are empty before 'zfs mount -a' runs (I've verified this with ls's
immediately before the 'zfs mount -a' in /lib/svc/method/fs-local).

| I'm not sure why you're not seeing truss show zfs trying to mount
| non-rpool filesystems, but it should be doing so.

 My truss traces on successful boot are quite definitive about this.
It clearly looks to see if a lot of fs's are mounted and finds that
they are. I've put one captured trace up here, if people are
interested:

	http://www.cs.toronto.edu/~cks/t/fs-local-truss-good-boot.txt

Notice that calls to libzfs:zfs_is_mounted() return either 0 or 1.
Calls that return 0 are followed by a call to libzfs:zfs_mount() (and an
actual mount operation); calls that return 1 aren't. Clearly 'zfs mount
-a' is checking a bunch more filesystems than it actually is mounting.

(I don't know if there's a way to make truss dump the first argument
to libzfs:zfs_is_mounted() as a string so that one can see what mount
points are being checked.)

 A truss from a bad boot is
	http://www.cs.toronto.edu/~cks/t/fs-local-truss-bad-boot.txt

This doesn't have the libzfs trace information, just the syscalls, but
you can see a similar sequence of syscall level operations right up
to the point where it does getdents64() on /h/281 and finds it *not*
empty (a 232-byte return value instead of a 48-byte one).  Based on
the information from the good trace, this is a safety check inside
libzfs:zfs_mount().

	- cks


More information about the OmniOS-discuss mailing list