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

[Richard Elling]

On Mar 5, 2014, at 1:38 PM, Chris Siebenmann <cks at cs.toronto.edu> wrote:

> It turns out that there is an unpleasant consequence to syseventd being
> willing to mount ZFS filesystems for additional pools before the 'zfs
> mount -a' has run: you can get unresolvable mount conflicts in some
> situations.

The basic problem affects other file systems, too. The general best practice
has always been to keep your hierarchy flat. But...

> 
> Suppose that you have /opt as a separate ZFS filesystem in your
> root pool and you also have /opt/bigthing as a ZFS filesystem in
> a second pool. You can set this up and everything looks right, but
> if you reboot and syseventd beats 'zfs mount -a' for whatever reasons,
> you get an explosion:
> 
> - we start with no additional filesystems mounted, including /opt
> - syseventd grabs the second pool, starts mounting things, and
>  mounts /opt/bigthing on the *bare* root filesystem, making /opt
>  (if necessary) in the process.
> - 'zfs mount -a' reaches /opt and attempts to mount it. However,
>  because syseventd has already mounted /opt/bigthing, /opt is not
>  empty. FAILURE.
> 
> As far as I can tell there is no particularly good cure for this.  To
> me it really looks like syseventd should either not be started before
> fs-local (although I don't know if anything breaks if its startup is
> deferred) or that it should not be mounting ZFS filesystems (although I
> can half-see the attraction of it doing so).

... a fix would necessitate building a multi-pool dependency tree. Where 
would this live?

How about if we put it in /etc?

This is effectively what vfstab does, though in a more simplistic manner: it 
simply sorts the list of file systems and mounts the short path first. The difference
between vfstab and ZFS automatic mounts is that the former can be multi-pool
aware, even if it doesn't know anything about pools at all. Hence the "solution"
is ZFS mountpoint=legacy and use vfstab.
 -- richard

--

Richard.Elling at RichardElling.com
+1-760-896-4422



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140308/d9a95191/attachment-0001.html>