On Fri, Aug 07, 2015 at 02:50:56PM -0500, William Hubbs wrote: > 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.
Let me add something to this after thinking about it more.
My concern is the need dependency is too strong; I think that if we
applied it in netmount the way it is being suggested, it would lead to
more situations than we currently have where things would fail and all
network file systems would be unmounted.
Here is my thinking about what's involved in the use vs want dependency
situation.
First, using the use dependency.
- All the sysadmin has to do is add nfsclient to the appropriate
runlevel, along with netmount. boom, it boots and you get your nfs
file systems.
If we use the want dependency, here is what happens (in pseudocode)
every time the depend() function of netmount is called.
find all network file system types
for fstype in network file system types; do
set wanted to false
query fstab for fstype file systems.
for fs in file systems from query; do
query fstab for the mount options for fs
if the mount options do not contain noauto set wanted to true
# Note we can't check for nofail here, because the mount -a
itself
# handles that,.
done
if wanted is true then add client to wantline
done
want $wantline
The dependencies for netmount have to be regenerated when fstab changes,
the init script changes, and possibly when the /etc/conf.d files
associated with it change; I'm not sure if this happens when you reboot
or not.
That just seems pretty heavy for a depend() function.
That is why I'm thinking using use and having folks add the clients to
their runlevels is the least of all the evils.
Thoughts?
William
signature.asc
Description: Digital signature
