Gentoo Archives: gentoo-dev

From: William Hubbs <williamh@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: rfc: improve file system mounting and unmounting in OpenRC
Date: Fri, 07 Aug 2015 22:51:18
Message-Id: 20150807225103.GA16783@linux1.gaikai.biz
In Reply to: Re: [gentoo-dev] Re: rfc: improve file system mounting and unmounting in OpenRC by William Hubbs
1 On Fri, Aug 07, 2015 at 02:50:56PM -0500, William Hubbs wrote:
2 > On Fri, Aug 07, 2015 at 03:30:41PM -0400, Ian Stakenvicius wrote:
3 > > -----BEGIN PGP SIGNED MESSAGE-----
4 > > Hash: SHA256
5 > >
6 > > On 07/08/15 03:18 PM, William Hubbs wrote:
7 > > > On Fri, Aug 07, 2015 at 01:39:25PM -0400, Ian Stakenvicius wrote:
8 > > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
9 > > >>
10 > > >> On 07/08/15 12:59 PM, William Hubbs wrote:
11 > > >>> On Fri, Aug 07, 2015 at 12:10:56PM -0400, Ian Stakenvicius
12 > > >>> wrote:
13 > > >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
14 > > >>>>
15 > > >>>> On 07/08/15 11:30 AM, William Hubbs wrote:
16 > > >>>>> On Thu, Aug 06, 2015 at 08:07:44PM -0400, Ian Stakenvicius
17 > > >>>>> wrote:
18 > > >>>>>>
19 > > >>>>>> Can we get "nofail" immediately in the mount -a variants
20 > > >>>>>> of localmount/netmount and expand that in netmount to
21 > > >>>>>> make the nfsclient dep be a "use" or a "need" depending
22 > > >>>>>> on if it's set or not?? That would imo kill the existing
23 > > >>>>>> bug that started all of this too.
24 > > >>>>>
25 > > >>>>> Sure, I can get the nofail support in pretty quick, and I
26 > > >>>>> think that is a feature we should have.
27 > > >>>>>
28 > > >>>>> Right now, netmount is using the use dependency to make
29 > > >>>>> sure network file system utilities are started before us.
30 > > >>>>> Because of the all-or-nothing nature of netmount, we can't
31 > > >>>>> switch those dependencies to need. It would cause netmount
32 > > >>>>> to fail if one of those utilities fails to start. The use
33 > > >>>>> dependency is the best one we can use at this time, and a
34 > > >>>>> migration path was specifically laid out in the news item.
35 > > >>>>>
36 > > >>>>
37 > > >>>> My thinking here is that, unless network mounts in fstab are
38 > > >>>> listed as 'nofail', that netmount failing due to the
39 > > >>>> dependent services not being able to start would be a valid
40 > > >>>> case. Sysadmins that don't want netmount to fail no matter
41 > > >>>> what would be able to use 'nofail' to ensure that happens.
42 > > >>>>
43 > > >>>> This is of course predicated on (1) it being a good idea,
44 > > >>>> and (2) fstabinfo or whatever the check currently is that
45 > > >>>> would add nfsclient to depend() could easily swap 'use' for
46 > > >>>> 'need' based on the (lack of) existence of the nofail
47 > > >>>> attribute in fstab.
48 > > >>>
49 > > >>> The issue with using the need dependency is that netmount is
50 > > >>> not granular enough. It mounts all types of network file
51 > > >>> systems, so if we fail because nfs is a need dependency and
52 > > >>> doesn't start, no other types of network file systems that use
53 > > >>> daemons will be mounted. That's what I meant by
54 > > >>> all-or-nothing.
55 > > >>>
56 > > >>> William
57 > > >>>
58 > > >>
59 > > >> Yes I follow that. My thoughts are #1, netmount (and localmount
60 > > >> for that matter) are all-or-nothing things; so if the service
61 > > >> fails then I don't think anything can necessarily be assumed as
62 > > >> to which mounts succeeded and which don't.
63 > > >
64 > > > Yes, they are, but mount and umount -a are not. They can report
65 > > > partial failures (check the exit codes).
66 > > >
67 > > > If I switch to using need dependencies for the file system clients,
68 > > > and one fails to start, mount -a would never run, which means NO
69 > > > net-based file systems that use clients would be mounted.
70 > >
71 > > Yeah I follow that, I just don't see that as something we need to
72 > > avoid given it can be avoided on systems by keeping netmount from
73 > > failing via 'nofail' on nfs mounts in fstab (or there being no 'auto'
74 > > nfs mounts in fstab to begin with)
75 > >
76 > > If the plan is that localmount and netmount will return error and fail
77 > > when one-or-more fstab entries with 'auto' and without 'nofail' can't
78 > > be mounted, then I see it as being convenient that netmount would
79 > > mount the other filesystems, but not imperative.
80 >
81 > That's exactly what mount -a -t ... does; it tries to mount everything
82 > of the specified types that does not have noauto in the options. If
83 > nofail is in the options for a file system, it doesn't report failure
84 > for that file system if it doesn't mount.
85 >
86 > I would rather err on the side of convenience in this case.
87 >
88 > >
89 > > (in case i wasn't clear earlier, i am talking about the 'need' vs
90 > > 'use' being dynamically chosen by the script; yes it's almost as evil
91 > > as the dynamic choices in depend() that might be necessary to do a
92 > > 'localmount' wrapper around mount.* services, but instead of it being
93 > > done for -everything- it's at least only done for one or a few corner
94 > > cases -- that being nfs mounts but there are likely others that need
95 > > daemons started at runtime)
96 > >
97 > >
98 > > > My thinking is to allow things to mount that can, but still report
99 > > > it as a failure if everything doesn't mount.
100 > >
101 > > Except for the fact that this isn't possible with a 'need' on
102 > > nfsclient, I think it's a great plan. :)
103 >
104 > Absolutely, and that is why I have issues with using "need" for
105 > file system clients like nfsclient.
106 >
107 > I see it as changing netmount's behaviour in a bad way.
108
109 Let me add something to this after thinking about it more.
110
111 My concern is the need dependency is too strong; I think that if we
112 applied it in netmount the way it is being suggested, it would lead to
113 more situations than we currently have where things would fail and all
114 network file systems would be unmounted.
115
116 Here is my thinking about what's involved in the use vs want dependency
117 situation.
118
119 First, using the use dependency.
120
121 - All the sysadmin has to do is add nfsclient to the appropriate
122 runlevel, along with netmount. boom, it boots and you get your nfs
123 file systems.
124
125 If we use the want dependency, here is what happens (in pseudocode)
126 every time the depend() function of netmount is called.
127
128 find all network file system types
129 for fstype in network file system types; do
130 set wanted to false
131 query fstab for fstype file systems.
132 for fs in file systems from query; do
133 query fstab for the mount options for fs
134 if the mount options do not contain noauto set wanted to true
135 # Note we can't check for nofail here, because the mount -a itself
136 # handles that,.
137 done
138 if wanted is true then add client to wantline
139 done
140 want $wantline
141
142 The dependencies for netmount have to be regenerated when fstab changes,
143 the init script changes, and possibly when the /etc/conf.d files
144 associated with it change; I'm not sure if this happens when you reboot
145 or not.
146
147 That just seems pretty heavy for a depend() function.
148
149 That is why I'm thinking using use and having folks add the clients to
150 their runlevels is the least of all the evils.
151
152 Thoughts?
153
154 William

Attachments

File name MIME type
signature.asc application/pgp-signature