Re: autofs linux 3.8.13 and "Too many levels of symbolic links"

[Donald Buczek <buczek@molgen.mpg.de>]

[-- Attachment #1: Type: text/plain, Size: 4441 bytes --]

Am 01.02.2014 03:57, schrieb Ian Kent:
> On Wed, 2014-01-29 at 17:02 +0100, Donald Buczek wrote:
>> Hello,
>>
>> we are trying to switch from amd to autofs. After successfully testing
> I didn't notice this before, so as an aside from our discussion
>
> You were (perhaps are) an amd user.
>
> As it happens I'm working on adding an amd map parser to autofs,
> probably for similar reasons to you needing to switch away from using
> it. I guess it won't make much difference to you since many people use
> amd for its cross platform abilities. And, well, there's that bug we're
> discussing ....
>
> But, fyi, let me tell you where it's at.
>
> I'm not sure how much of the functionality will end up in autofs quite
> yet but so far the things that likely won't be available are:
>
> - type program mounts
>    - needed in autofs too.
>    - but can't be done without significant autofs infrastructure
>      change (or they would have been done in autofs ages ago).
>    - would like to add this, probably some time later.
>
> - type nfsx mounts
>    - might (but probably not) get done for the initial commit.
>    - a bit hard to do within autofs.
>
> - type lustre mounts
>    - would like to do for initial commit but ....
>
> - type direct mounts
>    - I think I understand how these are supposed to work.
>    - don't work in amd on linux so can't check.
>    - can't find any references to users of them either.
>    - a bit difficult to do in autofs.
>    - undecided as yet, at best will do some time later.
>
> - map type passwd
>    - seems to prescriptive to be useful.
>    - unlikely to be implemented.
>
> - map type ndbm
>    - may implement later if people use it.
>    - would need to add to autofs as well for sane implementation.
>
> - configuration options not yet implemented
>    - fully_qualified_hosts
>    - unmount_on_exit
>    - browsable_dirs
>    - probably a couple of others I've missed.
>    - many of the configuration options aren't used or aren't
>      sensible within autofs.
>
> - man page for amd options
>    - autofs(5) will need to be updated before initial commit.
>
>
> I've probably missed a few things but this will give you an idea.
> My plan is to commit initial changes, announce this to try and get some
> testers and continue to work on it after that. Eventually the amd map
> changes will be autofs-5.1.0.
>
> Any interest in this?
> Ian
>

Well, to be true, we don't need anything of this. Where we have used 
some of the more complex map features of amd, I consider this a mistake 
and I'm happy to find  another solution for that. As small and simple as 
possible is what we would appreciate the most.

Even with the current autofs code, much of the complexity comes from 
features, we don't need (though I surly acknowledge that other do): 
direct maps, nested mountpoints, ldap maps, nis maps... We could even 
live without multithreading in the daemon. We could live without 
automatic selection between nfs and local bind mounts (because we build 
the maps on each node individually after we pushed around the 
configuration data). We could live without expiration support in kernel 
and daemon and just try to /bin/umount from our own scripts ourselves. 
I'm not to happy with uid/gid of the original mount persisting in kernel 
data structure, perhaps to see the daemon die on getpwuid() in two 
years, because the original account expired some month ago. For what? 
For /${uid}/ in the paths? Our goal is to provide a stable, global 
namespace to our nodes and not a "depends on who asked for it" namespace 
:-)

In our current setting, amd sits as a local nfs-server on the automount 
directories, so any path resolution of an already mounted subdirectory 
still goes through RPC serialisation and context switches and a big, 
buggy user-mode daemon. This is the great performance and stability 
problem we want to get rid of, so we go for in-kernel autofs. I think, 
in the latest versions of amd they are working on supporting autofs too, 
but we had too many bad experience, we don't want to upgrade amd away 
from our more or less stable version. So, please, autofs/automount, 
don't become a second amd, stay as small and simple and fast and bugfree 
as possible. Just my view.

Regards
   Donald

-- 
Donald Buczek
buczek@molgen.mpg.de
Tel: +49 30 8413 1433



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4541 bytes --]