Frank Lenaerts wrote: > Paul Smith wrote: > > %% Regarding Re: autofs vs amd: Is there a preference?; > > ao> autofs vs amd is like tinydns vs bind or exim vs sendmail ( its
The wars between autofs and amd are legion. > > Like /net. Which almost every enterprise environment I've seen makes > > heavy use of. Alvin writes: > autofs is sorta broken in most distro... you need to tweek the config > files to get it to do what you want Agreed. I *always* have to modify it to /net. Although broken is probably too harsh. Is there a standard there? I don't know and it does not matter for me since I must configure it to /net or my neck goes in the noose. It is the defacto location. > I didn't know there was such a big performance penalty in using amd > versus autofs (it doesn't mean that because autofs is partly kernel > space, that it is by definition twice as fast or so). Anyway, I don't > think most people base their choice of amd versus autofs on a > performance basis. It's more a difference of how both are implemented > internally, especially regarding the so called pwd problem. Performance is application specific. AMD seems to be slower when resolving full paths like /net/host/path/to/file probably because of the threading to prevent blocking. But relative paths like ./file are the same between them since that bypasses the automounter directory entirely. Therefore some programs will have no difference in performance and other programs will show performance difference. One application out of hundreds here runs in 30 seconds with autofs and 4 minutes 30 seconds with amd. None of the others showed any difference. That pushed us solidly into autofs space however as it was a critical application. But you would just have to try your particular programs in the two environments and measure it yourself if it was important. For most environments it is purely personal preference. The classic argument is that amd is threaded and so won't block if one server is not responding and by running in user space is more controllable. So in a broken environment amd tends to degrade more gracefully. But in a working environment autofs problems are not hit and the performance there is generally better. It is hard to say "working NFS environment" because to many of us that is an oxymoron. The tradeoff is robustness versus speed and autofs features. Some programs have trouble with the symlink farm, as pwd is not in the trigger directory. Therefore autofs is a better choice for non automounter aware software. When amd implements that fully it will level this part of the playing field. > > OTOH, my neighbor just enabled autofs on his RH 8 system today after > > weeks of using amd with no problems, and he had hardly started doing > > anything when the kernel oopsed in the autofs code. > > Strange, I have been using it for more than a year, without any > problems (these were Debian boxes however;-)) The autofs in 2.4.18 on x86 is rock solid. So is the am-utils' amd. I only suffer from the unavoidable NFS issues due to the design of NFS and I can't blame either automounter for those problems. Bob
msg26221/pgp00000.pgp
Description: PGP signature
