tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ZFS - mounting filesystems (Was CVS commit: src/etc)

Simon Burge <> writes:

> Lots of interesting discussion!  Thanks all.

As a loud ranter I'll comment briefly but thanks for the summary and I
think we're heading for a good place.

> Broadly I think I can summarise to the following options:
>  1. The existing critical_filesystems_zfs rc.conf variable, which
>     mixes ZFS configuration in both rc.conf and with ZFS itself.

If this works, which it by all accounts seems to, the only real problem
is that some people (and I can see why) would like to manage the
critical property with a zfs property to keep all their zfs config in
the same place.  Am I misperceiving?

>  2. Add ZFS "critical" properties for filesystems and mount those
>     in /etc/rc.d/mountcritlocal .
>  3. Move all ZFS mounts to /etc/rc.d/mountcritlocal .

3 is the only thing here I object to because it is architecturally
unclean, giving special semantics to zfs.

>  4. Optionally move all ZFS mounts to /etc/rc.d/mountcritlocal
>     controlled by an rc.conf variable (eg zfs_critical).

I view this as syntactic sugar for putting all zfs mounts in the
critical_filesystems_zfs variable.  It's a little to close to option 3
for my taste, but I won't say I object.

>  5. Move all local mounts to /etc/rc.d/mountcritlocal (ala
>     FreeBSD) and possibly rename this to /etc/rc.d/mountlocal .

I think the only thing we lose with this is the ability to mount local
filesystems on top of mount points that are in remote filesystems,
without playing the noauto/rc.local game.  I am ok with this personally,
but it feels hard to be sure it won't cause trouble, and I do expect
some trouble.

>  6. "Intelligent" ordering based on prefixes, tsort, etc.

> In terms of what to do for the up-and-coming netbsd-10 (although the
> actual release will still be a little whiles away), I think there
> appeared to be broad concensus on that option 2 was reasonable.  I will
> try to get an implementation of that ready.  If that's not ready in time
> for netbsd-10 I think option 4 is probably least intrusive fallback
> especially because it's optional.

It may be that after that is done, there is no real reason based on the
zfs concerns to change anything else.

> critical_filesystems_zfs is still available now, and will be available
> going forward.
> Option 3 doesn't seem to buy anything if option 4 is available and
> option 5 seems like it could be more impactful to existing mixed local
> and NFS setups.


> Option 6 I think is out of scope of what I want to get root-on-ZFS
> working.  That doesn't stop others from fleshing this out of course!
> Thoughts?  Anything I've missed?

I think you got it exactly right.

> And somewhat related that came out of this discussion - add a "noerror"
> or "notfatal" or some similar keyword that says a failed fsck or mount
> doesn't automatically fail the boot and fall back to single user mode.

That would be good.

> Although Ignatios had an interesting solution to this with "noauto" and
> using @reboot crontab entries.

Sure, you work around the lack of the feature, but that doesn't mean a
simpler way is bad.

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index