Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Mar 2008 23:40:43 +0200
From:      "Adrian Penisoara" <ady@freebsd.ady.ro>
To:        "Zaphod Beeblebrox" <zbeeble@gmail.com>
Cc:        freebsd-hackers@freebsd.org, freebsd-rc@freebsd.org
Subject:   ZFS startup scripts (was Re: On ZFS and 64/32 dual-booting.)
Message-ID:  <78cb3d3f0803101440l54384d82rf57044aa9418efdf@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
Hi,

 In particular to ZFS rc.d scripts comments below...

On Sat, Mar 8, 2008 at 9:53 PM, Zaphod Beeblebrox <zbeeble@gmail.com> wrote:
[...]

> === What doesn't work OOTB ===
>
> The startup scripts for ZFS are still a little green.  One issue is that
> the
> startup script 'requires' mountcritlocal --- I assume because it figures
> it
> requires it so that it's own filesystems will mount on top of other local
> UFS ones.  At least in my case, this is backwards.  I need zfs to run
> BEFORE
> mountcritlocal and BEFORE mdconfig.  I have changed my require line to
> 'root


  I'm not sure why you would need to have ZFS filesystems up before
mdconfig. However, if you need ZFS volumes up before mdconfig, that's
understandable and it is easily doable with a split ZFS startups scripts
configuration, like the one I proposed in PR conf/120228 (
http://www.freebsd.org/cgi/query-pr.cgi?pr=120228 ). Basically the ZFS
volumes initialization needs to occur as a "disks" requirement.


>
> hostid' ... since it's good to have the hostid already set and having root
> r/w is also good.  I don't think I've solved the "BEFORE" problem, but the
> my requirements might make it into the CVS tree.
>

  Actually, to respect the Un*x philospphy, I think you would need to list
the "critical" filesystems in /etc/fstab. You could do that by specifying
the filesystem type "zfs" and the ZFS path as device node, e.g., for a
sysvol pool with "usr" filesystem:

system/usr          /usr            zfs            rw
0                0

  Otherwise I think you are right, ZFS filesystems mounting should occur
around the same time as "mountcritlocal". I have done a test with the
following /etc/rc.d/zfs script header and appears to do the trick (you don't
have to list the individual ZFS mounts in /etc/fstab):

# PROVIDE: mountcritlocal zfs
# REQUIRE: root

 However, that change proved to be unnecessary (and perhaps wrong) since
/etc/rc.d/FILESYSTEMS already lists zfs as a dependency and most of the
scripts keep FILESYSTEMS as a requirement.

 You would still need to use vfs.root.mountfrom in /boot/loader.conf to
start from a ZFS filesystem root.


>
> This dependancy issue is an interesting one.  I assume that the fstab code
> make sure that filesystems are mounted in a sane order ... or maybe it's
> just the order in the file itself --- I've never had a problem, so I don't
> know.  However, having this information in two places poses the immediate
> problem... one person might have a ufs /usr and a zfs /usr/ports and
> another
> might have a zfs /usr and a ufs or nfs /usr/home.  Calling zfs mount -a
> either before or after mountcritlocal isn't going to make everyone happy.
> Maybe it needs to be called both times?  I dunno.  I dunno if zfs can fail
> gracefully when things it needs arn't mounted yet.
>

  I guess FreeBSD philosophy (and Un*x in general) is to keep all
filesystems to be mounted in /etc/fstab -- this way the order would be quite
clear. Since this occurs in [/etc/rc.d/]mountcritlocal and mountcritlocal is
listed as a requirement in /etc/rc.d/zfs, then you can rest assured that
"zfs mount -a" will occur after mounting stuff in /etc/fstab.
   If you need to have an exception then forcibly mount it early in
/etc/fstab (I guess you should do that anyway for important mountpoints like
/usr and /var).

[...]

>
>   2. Dependencies of /etc/rc.d/zfs need rethinking


Check proposed patch in above quoted PR. Let me know if you have comments on
that.

Thank you,
Adrian Penisoara
ROFUG / EnterpriseBSD



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?78cb3d3f0803101440l54384d82rf57044aa9418efdf>