Re: [gentoo-dev] Re: rfc: improve file system mounting and unmounting in OpenRC

[William Hubbs]

On Fri, Aug 07, 2015 at 03:30:41PM -0400, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 07/08/15 03:18 PM, William Hubbs wrote:
> > On Fri, Aug 07, 2015 at 01:39:25PM -0400, Ian Stakenvicius wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> >>
> >> On 07/08/15 12:59 PM, William Hubbs wrote:
> >>> On Fri, Aug 07, 2015 at 12:10:56PM -0400, Ian Stakenvicius
> >>> wrote:
> >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> >>>>
> >>>> On 07/08/15 11:30 AM, William Hubbs wrote:
> >>>>> On Thu, Aug 06, 2015 at 08:07:44PM -0400, Ian Stakenvicius
> >>>>> wrote:
> >>>>>>
> >>>>>> Can we get "nofail" immediately in the mount -a variants
> >>>>>> of localmount/netmount and expand that in netmount to
> >>>>>> make the nfsclient dep be a "use" or a "need" depending
> >>>>>> on if it's set or not??  That would imo kill the existing
> >>>>>> bug that started all of this too.
> >>>>>
> >>>>> Sure, I can get the nofail support in pretty quick, and I
> >>>>> think that is a feature we should have.
> >>>>>
> >>>>> Right now, netmount is using the use dependency to make
> >>>>> sure network file system utilities are started before us.
> >>>>> Because of the all-or-nothing nature of netmount, we can't
> >>>>> switch those dependencies to need. It would cause netmount
> >>>>> to fail if one of those utilities fails to start.  The use
> >>>>> dependency is the best one we can use at this time, and a
> >>>>> migration path was specifically laid out in the news item.
> >>>>>
> >>>>
> >>>> My thinking here is that, unless network mounts in fstab are
> >>>> listed as 'nofail', that netmount failing due to the
> >>>> dependent services not being able to start would be a valid
> >>>> case. Sysadmins that don't want netmount to fail no matter
> >>>> what would be able to use 'nofail' to ensure that happens.
> >>>>
> >>>> This is of course predicated on (1) it being a good idea,
> >>>> and (2) fstabinfo or whatever the check currently is that
> >>>> would add nfsclient to depend() could easily swap 'use' for
> >>>> 'need' based on the (lack of) existence of the nofail
> >>>> attribute in fstab.
> >>>
> >>> The issue with using the need dependency is that netmount is
> >>> not granular enough. It mounts all types of network file
> >>> systems, so if we fail because nfs is a need dependency and
> >>> doesn't start, no other types of network file systems that use
> >>> daemons will be mounted. That's what I meant by
> >>> all-or-nothing.
> >>>
> >>> William
> >>>
> >>
> >> Yes I follow that.  My thoughts are #1, netmount (and localmount
> >> for that matter) are all-or-nothing things; so if the service
> >> fails then I don't think anything can necessarily be assumed as
> >> to which mounts succeeded and which don't.
> >
> > Yes, they are, but mount and umount -a are not. They can report
> > partial failures (check the exit codes).
> >
> > If I switch to using need dependencies for the file system clients,
> > and one fails to start, mount -a would never run, which means NO
> > net-based file systems that use clients would be mounted.
>
> Yeah I follow that, I just don't see that as something we need to
> avoid given it can be avoided on systems by keeping netmount from
> failing via 'nofail' on nfs mounts in fstab (or there being no 'auto'
> nfs mounts in fstab to begin with)
>
> If the plan is that localmount and netmount will return error and fail
> when one-or-more fstab entries with 'auto' and without 'nofail' can't
> be mounted, then I see it as being convenient that netmount would
> mount the other filesystems, but not imperative.

That's exactly what mount -a -t ... does; it tries to mount everything
of the specified types that does not have noauto in the options. If
nofail is in the options for a file system, it doesn't report failure
for that file system if it doesn't mount.

I would rather err on the side of convenience in this case.

>
> (in case i wasn't clear earlier, i am talking about the 'need' vs
> 'use' being dynamically chosen by the script; yes it's almost as evil
> as the dynamic choices in depend() that might be necessary to do a
> 'localmount' wrapper around mount.* services, but instead of it being
> done for -everything- it's at least only done for one or a few corner
> cases -- that being nfs mounts but there are likely others that need
> daemons started at runtime)
>
>
> > My thinking is to allow things to mount that can, but still report
> > it as a failure if everything doesn't mount.
>
> Except for the fact that this isn't possible with a 'need' on
> nfsclient, I think it's a great plan.  :)

Absolutely, and that is why I have issues with using "need" for
file system clients like nfsclient.

I see it as changing netmount's behaviour in a bad way.

William