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 testingI 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@xxxxxxxxxxxxx Tel: +49 30 8413 1433
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
