I apologize for failing to understand "zfs legacy mount" and incorrectly
associating it with how I usually encounter the word legacy.
I now understand that you meant to separate:
zfs's preferred path of having mountpoints stored as volume
properties, which is a different way of specifying what is mounted
where than everything else, but makes sense in a world with many zfs
volumes
having a zfs volume where instead of the normal zfs way, there is an
fstab entry
So having re-thought I would say:
It makes sense to have a boolean "critical" property (the name you
suggested is fine) for zfs volumes that specify a mount point, so that
such volumes would be mounted in mountcritlocal. I am 100% happy for
someone to add that and see no big problems.
It makes sense to just put zfs volume mountpoints in
critical_filesystems_local, if those volumes use the fstab method
instead of mountpoint properties (i.e., are "zfs legacy mounts").
I think this is tricky if there are multiple pools and some don't come
up. But I think it's ok if the main path is that one should have all
critical zfs filesytems on the same pool as root, with root on zfs.
With root not on zfs but say /usr and /var on zfs, there needs to be
some way for the boot to fail if they aren't mountable, just like if
they were in fstab, if the pool doesn't attach and thus the critical
variable aren't readable. That might mean "if root is not zfs, and
something in critical_fileystems_{local,remote} is in zfs, then those
things have to use zfs legacy mounts". It might mean having
"critical_zfs_pools_{local,remote}" which will fail the boot if they
are not attached at the mountcritlocal/mountcritremote stage, so that
the critical properties are reliably there.
I am opposed to deciding that all zfs filesystems should be treated as
critical (in a world where we have not abolished the notion).
We could have a discussion about why we even have the concept of
critical filesystems, but if so that should not be about zfs and
should be in a new thread on tech-userlevel. And, I think it really
isn't strongly releated to this discussion.
for background, I used to understand the critical filesystem scheme
better, but I'll briefly say (projecting to modern rc.d) that I think
it's about sequencing getting enough filesystems mounted to be able to
hit the NETWORKING rc.d barrier. Consider a diskless workstation with
separate / and /usr (because /usr is shared across all 10 Sun 3/50s :-)
that also needs to mount some other filesystem from a server beyond the
LAN, which requires running routed. Sorry if that gives yuo bad
flashbacks to the 80s :-)
In modern NetBSD I put /var and /usr in critical_fileystems_local,
because I want route6d to start, and that's in /usr/sbin. Arguably
route6d should be in /sbin, or NETWORKING should be split into things
needed to talk to the local link vs the broader network, but I have
avoided digging in because adding a line to rc.conf is easy, and moving
route6d would be actual work.
Greg
Attachment:
signature.asc
Description: PGP signature