On Tue, 24 May 2005, Miklos Szeredi wrote:
> > > Does it work if somebody renames a directory in the path leading to
> > > the autofs mountpoint? The result is very similar to move mount.
> >
> > Don't know but I doubt it.
> > I don't think it should because autofs needs be true to the mount maps
> > that define what automounts are to be provided.
>
> OK. Then you can just say that move mount isn't supported.
>
> You can't stop a stupid sysadmin from messing up the system, so you
> shouldn't really try.
>
> Of course even in this case there shouldn't be anything nasty (like
> Oops or panic), but I think it's OK if it simply won't work anymore.
>
> > > You could solve both, by having the automoutnter daemon chdir to the
> > > autofs root, and then it would just not care about any namespace
> > > changes outside it's own filesystem.
> >
> > Perhaps but I think it will not be that simple.
> > It's worth thinking about.
> >
> > I'm working on providing full direct mount support atm (I have limited
> > functionality now).
>
> Can you please explain what "direct mount" is? I'm not really
> familiar with automount terminology.
The mounts appear in a map whose source can be a file or NIS or other
supported repositiry. A master map tells autofs where to find the actual
mount maps.
All automount maps can be classified as either indirect or direct.
An indirect map looks like:
in the master map
/home /etc/auto.home
in auto.home
user1 server1:/home/user1
user2 server1:/home/otheruser
and so on.
A direct map looks like
in the master map
/- /etc/auto.direct
in auto.direct
/usr/share/man server:/usr/share/${OSNAME}-${OSVER}/man
/nfs/thishost/thisdata anotherserver:/local/data/thisdata
and so on.
There are other things that can be used in maps such as wild card key
matching and substitution and the like.
>
> > I will have many autofs mounts handled by a single daemon. So that
> > makes it a bit harder. This will be done using a file handle to
> > identify (for map entry lookup) each direct mount point in the map,
> > but still I suspect the corresponding vfsmount will end up being
> > wrong. I'm also thinking of doing this for indirect mounts during
> > this rework. A similar approach I think, to what you describe below.
> >
> > I must point out that my current focus is to push the current autofs
> > implementation as far as it can go within its original design. Which is
> > probably not much further than implementing functionaly workable direct
> > mounts. This means that multiple namespace support is not under
> > consideration. Indeed the current design will not easily lend itself to
> > it.
> >
> > Mike Waychison was working on a new version to address this and other
> > limitations of the current design but development of this seems to have
> > stopped.
>
> I've just seen those patches (Mike pointed them out to me in another
> thread).
>
> > I saw that code when I was looking at this problem.
> > It looks quite interesting.
> > Again, I'll have to think about it.
> > Changes of that magnitude won't happen quickly.
> > It's already been a hard slog to get autofs to a reasonably stable state.
> >
> > When I was looking at it I didn't see anything that would help with some
> > of the issues such as:
> >
> > 1) lazy mount/umount/expire of a tree of mount points (needs to be handled
> > atomically).
> > 2) Didn't see anything relating to expire timeouts just busyness.
> > 3) I don't think that item (1) in the file you refer to above is correct.
> > The nameidata struct passed to follow_link assumes that a mount point has
> > not been followed prior to the call. So this approach can't work for
> > direct mounts without some more work in the VFS. Maybe it can be done
> > another way but I'm not aware of it.
> > 5) It seems that exporting the vfsmount_lock so it can be used in a
> > module is not good pratice (at least that was the case the last time I
> > needed it).
> >
> > Please don't get me wrong. I did notice this code (but not the doco) and
> > it does look really useful to me but it means a significant redesign of
> > autofs. I need what's currently in place to work as it's likely to be
> > around for quite a while yet.
>
> I'm not too familiar with that code either, and I'm not trying to
> convince you either way :)
>
> I think it does address the atomicity issue, but requires special
> do_add_mount() call (which places the vfsmount on the expiry list), so
> it probably needs some work to export that functionality to userspace
> mounts.
>
> > What I really need is agreement that adding a super_operations method such
> > as "mount" is acceptable so that I can veto bind and move mounts with the
> > current version. Perhaps I can do it another way ?????
>
> If you just want to disable bind (so that it doesn't cause trouble),
> the simplest way seems to be to remember the original vfsmount, and
> just ignore any lookups in other vfsmounts. You can do this, since
> the vfsmount is passed in the nameidata parameter of dir->lookup().
>
> Then bind will succeed, but the autofs will simply not do anything in
> the copied mount. I think that would be much cleaner than trying to
> veto a bind request.
Not sure that will be without pain down the track from a support
viewpoint.
Thanks for your advice
Ian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
