-----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. (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. :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlXFB2EACgkQAJxUfCtlWe1VkAEA0YhNvBeeRQRg0Bl1RWAniDvO vspzbj73u+ed8pRZt6UBALIwLqsY2V1fQo/UWeyELjzQijg8TtRHCqz7iVpT4kMf =e3K5 -----END PGP SIGNATURE-----
