Taylor R Campbell <campbell+netbsd-tech-userle...@netbsd.org> writes:

>> Date: Thu, 17 Mar 2022 08:32:40 -0400
>> From: Greg Troxel <g...@lexort.com>
>> 
>> Simon Burge <sim...@netbsd.org> writes:
>> 
>> >  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.
>
> Does anyone actually do this -- have local mounts on top of remote
> mounts?
>
> I keep hearing about the theoretical possibility of /usr on nfs and
> /usr/src or /usr/local on local ffs.  But you'd really have to go out
> of your way to set that up -- certainly sysinst won't do that for you.
> Not sure it's too much to ask that if you do set something up like
> that you use noauto/rc.local or a local rc.d script to manage it.
>
> Is this obscure use case actually worth worrying about enough to add
> new knobs, invent new NetBSD-specific zfs properties, and/or keep a
> confusing series of mount stages in rc.d?
>
> I think it would be better to just nix the `critical' distinction:
> mount root, then mount all local, then start networking and mount all
> remote.  Keep it simple unless there's a strong reason not to.

It is really hard to assess the costs of these two paths over all users
and uses.

I don't object to mounting all local in mountcritlocal (and I don't care
if it is renamed to mounlocal).  I don't want to commit that personally,
since I don't want to bite off responsibility for fixing problems I
didn't anticipate.

Right now, mountcritremote comes before servers/etc. and the rest can
happen later, in mountall.  Right now for almost everyone
mountcritremote does nothing.  That does't have a compelling reason for
change, so there's only risk of breaking things we don't understand, and
I'm inclined to leave it.

Attachment: signature.asc
Description: PGP signature

Reply via email to