On Mon, 2021-04-12 at 20:40 +0200, Frank Thommen wrote: > > On 11.04.21 04:58, Ian Kent wrote: > > On Sat, 2021-04-10 at 23:50 +0200, Frank Thommen wrote: > > > On 09.04.21 02:50, Ian Kent wrote: > > > > On Thu, 2021-04-08 at 19:50 +0200, Frank Thommen wrote: > > > > > Dear all, > > > > > > > > > > I have problems "submounting" a share when using direct > > > > > mounts. > > > > > Given > > > > > the following automounter tables: > > > > > > > > > > /etc/auto.master: > > > > > ----------------------------------- > > > > > /- /etc/auto.groups > > > > > > > > > > > > > > > /etc/auto.groups > > > > > ----------------------------------- > > > > > /groups/group1/int server:/export/group1 > > > > > /groups/group1/int/svc/a server2:/export/service_a > > > > > /groups/group2/int server2:/export/group2 > > > > > /groups/group3/int server:/export/group3 > > > > > [... ca. 100 entries here ...] > > > > > > > > > > > > > > > /groups/group1/int/svc/a is not mounted and I get the error > > > > > message > > > > > "do_mount_autofs_direct: failed to create mount directory > > > > > /groups/group1/int/svc/a" on any host which doesn not have > > > > > root > > > > > permissions (no_root_squash) on server:/export/group1 (which > > > > > is > > > > > on > > > > > 99% > > > > > of all clients). > > > > > > > > autofs won't (shouldn't) create directories in remote file > > > > systems > > > > to perform mounts, it requires they are already present. > > > > > > > > > The directory "svc/a" has been created on > > > > > server:/export/group1, > > > > > so > > > > > there is no need to recreate it. > > > > > > I am sure autofs /did/ recreate it. But I will doublecheck that. > > > > I think you'll find the directory must already exist on the server > > in this case since it's inside a containing NFS mount. > > > > If it doesn't exist mounting the offset trigger will fail and the > > non-strict default can lead to other problems if that mount is > > expected to be there (non-strict is mean to prevent fails from > > administrative access restrictions on mounts to hosts rather > > than this case). > > Hm. I checked. Yes, it seems, that the directory has to be created > on > the server, *but* on a server which has root permissions on the > "base" > share (/groups/group1/int, i.e. server:/export/group1), I see the > following entries in the autofs debug log (note the call to > "mkdir_path"): > > automount[18052]: mount_mount: mount(nfs): calling mkdir_path > /groups/group1/int/svc/a > automount[18052]: mount(nfs): calling mount -t nfs4 -s -o > vers=4.0,rw,sec=sys server2:/export/service_a > /groups/group1/int/svc/a > automount[18052]: mount_mount: mount(nfs): mounted > server2:/export/service_a/icgc/dmg/otp on /groups/group1/int/svc/a > automount[18052]: mounted /groups/group1/int/svc/a > > and there is a mount in place at that path > > > On a server which does *not* habe root permissions on the base share, > I > get a > > automount[21701]: do_mount_autofs_direct: failed to create mount > directory /groups/group1/int/svc/a > > and there is /no/ mount in place at that path. > > I don't understand that... What is it you don't understand? > > > > > > Which you have done. > > > > Presumably the permissions are ok? > > > > > > Are special permissions required? > > > > Well, no, but I have seen strange behaviours with restricted > > permissions settings, it shouldn't be a problem I guess. > > > > > > I haven't looked at this case for a very long time but I'm > > > > pretty > > > > sure nesting isn't allowed in direct mount maps (with any map > > > > type > > > > really). I'm also pretty sure I don't test for nesting in > > > > direct > > > > mount maps (quite difficult to do) and fail the trigger mount. > > > > > > > > If you need to nest mounts your supposed to use offsets in the > > > > mount entry (with both direct or indirect maps). > > > > > > > > For example: > > > > /groups/group1/int / server:/export/group1 > > > > /svc/a server2:/export/service_a > > > > > > > > where the "/" for the root offset is optional but may help with > > > > map readability. > > > > > > I wasn't aware that multi-maps were also possible with direct > > > maps. > > > > Ha, multi-mount please, multi-maps are a different feature and we > > don't want to get confused. > > > > > However we had major issues with updating such configurations, as > > > an > > > update of the "nested" part requires an autofs re/start/, while > > > otherwise a re/load/ suffices. We must avoid autofs restarts in > > > our > > > > Actually I think that's not quite what is happening. > > > > I'm going by memory here so I might not be completely accurate. > > > > The re-load will update the map entry that has the offsets but > > the mounts won't change until the multi-mount is mounted again > > from it's base. > > > > IIRC the internal hosts map will try and re-configure the offsets > > of the mounted multi-mount on re-load but I haven't expanded that > > multi-mount feature to other areas. > > > > Expanding that that is one possible way I could help but equally > > the umount vs. mount order fix on re-load needs to be done too. > > > > > environment at all costs, as they can lead to short interruptions > > > in > > > the > > > accessibility of shares, which is a problem in a cluster > > > environment > > > where theses accesses happen all the time. See also our long > > > thread > > > "Changes in indirect multi-maps don't become effective w/o autofs > > > restart" in 2019 ;-) > > > > Ok, I don't remember that so I'm not sure what I said or did or > > didn't do. But the situation I described above is essentially > > what we have and so far I had only implemented it for the > > internal hosts map. > > > > The fact is that without a policy that minimises disruption on > > mounts that are busy sufficient for a broad range of environments > > the only choice is to ignore that bit of the update (and anything > > below it) until it expires. > > > > The bottom line is that if the update is forced some processes > > will end in tears sooner or later and there's no way around it. > > > > Fixing the mount/umount ordering on reload seems like the simplest > > improvement but, again, in use mounts will be a problem. > > > > > From what I've seen forcing the update by lazy umounting the busy > > mount(s) is probably the least disruptive way to do it but that > > will mean the change will be more extensive since I try and avoid > > doing that by ignoring these (which I think is the cause of a fair > > amount of the problems your seeing). > > > > > If I may digress with a short syntactical question: Is the \ at > > > the > > > end > > > of the line in multi-maps not required? This would explain > > > strange > > > effects that we had when we indented some of the keys in some > > > direct > > > maps (to enhance readability) > > > > My mistake, the line continuation is definitely needed there. > > > > > > > > > I've not seen problem reports like this from direct mount map > > > > users > > > > so I'm pretty sure nesting isn't normally used so I'm not sure > > > > it > > > > will work properly. > > > > > > > > However the testing I use does include pass/fail tests for > > > > direct > > > > mount map entries with offsets so it should work. > > > > > > > > There could unfixed problems with the version of autofs you are > > > > using > > > > which we would need to look at separately. > > > > > > > > > There are additional subdirectories in > > > > > /groups/group1/int/svc/ > > > > > which > > > > > directly reside on server:/export/group1. Only "a" need to > > > > > be > > > > > mounted > > > > > from a second location. > > > > > > > > I think this should work fine using an offset as described > > > > above. > > > > > > > > Those other directories are present in the mount that contains > > > > the > > > > offset trigger so it should appear the same as you were hoping > > > > the > > > > original map entry would except that by using an offset the > > > > expire > > > > should now work. > > > > > > > > > Can this be solved with direct mounts? How? We would prefer > > > > > to > > > > > use > > > > > direct mounts, as this has shown to create the least problems > > > > > when > > > > > dynamically changing the mount tables (no automounter restart > > > > > is > > > > > required). However I would not have a problem to use some > > > > > indirect > > > > > mount mechanism for /groups/group1/int/svc/a as long as the > > > > > main > > > > > /groups/groupN/int can stay in a direct mount table. > > > > > > > > But you do need to do a reload for the direct mount triggers to > > > > be updated, right? > > > > > > yes a reload is required, but a reload doesn't disrupt access to > > > NFS > > > shares while a restart can/does (which is a major issue in our > > > cluster > > > environment, see above) > > > > Yep, I get that and that pause in access is a problem I'm aware of, > > and it's a problem that I can't resolve, and it's particularly bad > > for busy sites, such as yours. > > > > Anyway, you've got me at a good time to get some attention on this, > > just don't don't let me forget about it if I get loaded with other > > things ... > > So if understand correctly, you see a possible way to alleviate (but > not > completely solve) the situation with mount disruptions. What > can/should > I do to not let you forget about it? ;-) > > > Frank > > > Ian > > > >
