Simon Burge <simonb%NetBSD.org@localhost> 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. Agreed. > 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