Re: Changes in indirect multi-maps don't become effective w/o autofs restart

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2019-05-16 at 09:28 +0800, Ian Kent wrote:
> On Thu, 2019-05-16 at 09:01 +0800, Ian Kent wrote:
> > 
> > > We are running autofs-5.0.7-70.el7_4.1.x86_64 on CentOS 7.4.1708 and we 
> > > cannot update to newer CentOS releases due to other restrictions 
> > > (special hardware/drivers).
> > 
> > Mmm ... CentOS 7.4, that's a while ago so I'm not sure if the
> > changes are present but I suspect they are.
> > 
> > So it's likely the changes made for this are not working properly.
> > 
> > I'll check if the changes are present (it will take a while as
> > I'll need to track down what those changes were first) and try
> > to duplicate it to see what's going on.
> 
> Yes, that's not working properly even with the current upstream
> code.
> 
> I'll look further into it.

I can't find the changes I was thinking of but I did find some
changes I did for updating the internal hosts map on re-read
since this map essentially turns the list of exports into a
multi-mount map entry for each host.

I think that I did that to see how it would go and was planning
of going further with it if there were no adverse reports.

But looking at it again now, in spite of not seeing reported
problems with it, I'm very reluctant to do it for multi-mounts
in general.

The problem with updating multi-mounts is it's very easy to get
problems similar to the dead mount problem you've recently already
encountered due to mount dependencies within the mount tree.

For example if you have:

ent \
	/s1	   <server>:/<path1> \
	/s1/s2/s3  <server>:/<path2>

and it changes to:

ent \
	/s1	   <server>:/<path1> \
	/s1/s2	   <server>:/<path3> \
	/s1/s2/s3  <server>:/<path2>

then I need to ensure that the mount trigger mounted on <base>/s1/s2/s3
is umounted before mounting the mount trigger on <base>/s1/s2 and then
remount the mount trigger on <base>/s1/s2/s3.

If there's an actual mount on <base>/s1/s2/s3 you can't do the update
for this offset until the real mount gets umounted leading to partially
updated multi-mounts that don't look like the updated map should and
might not be able to be reverted to behave like the original either.

Ian




[Index of Archives]     [Linux Filesystem Development]     [Linux Ext4]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux