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 |