On Tue, 22 Nov 2005, Brian Long wrote:

> I have an auto.master deployed to thousands of hosts and it looks like
> this:
> 
> /misc   /etc/auto.misc          --timeout=60
> /auto   /etc/auto.indirect      rsize=32768,wsize=32768,tcp
> /users  auto_home               rw,hard,intr,rsize=32768,wsize=32768,tcp
> 
> As you can see, /users comes from NIS auto.home map.  In our case,
> auto.home contains over 34,000 entries.  I've noticed in RHEL 3 U5 and
> beyond (autofs-4.1.3-130), trying to stat (ls) /users/no-such-user takes
> roughly 12-15 seconds.  In RHEL 3 U3 (autofs-4.1.3-12), it returns
> immediately.  This is a regression in my opinion.

Bummer. I thought that update code was OK.

> 
> After looking at tcpdump data, it appears automounter is downloading the
> entire auto.home map when it fails to lookup "no-such-user".  This
> results in a > 700KB transfer from the NIS server  :(

This is exactly the sort of problem I was concerned about when people 
asked for periodic reload of maps. I didn't do that and clearly I was 
right.

Having said that it possibly shouldn't be doing this either. I'll have to 
check the lookup code to see what I'm doing.

Probably I'm signaling a re-load because, since the entry is now missing, 
the map may need to be updated.

I hasten to point out there was quite a bit of demand for having "up to 
date maps"! Having a HUP signal to force a re-load wasn't enough.

Given your situation and the fact that we need to know about changes, what 
do you think the semantics of handling map updates should be?

Seems to me there are only two options when an out of date map entry is 
encountered. Update, remove or add the given entry and accept there may be 
more you don't know about or re-read the whole map. Now even the simple 
addition and removal is not simple as the lookup is done in a subprocess 
so somehow the process leader needs to be told what to get!

Did someone ask what would be the advantages of turning autofs into a 
threaded app?

> 
> In the older autofs version, it does NOT do this.  I have opened a Red
> Hat issue tracker (82760), but in parallel I wanted to ask this list if
> this is known behavior and if there is any way I can disable the
> download of the entire auto.home map using /etc/sysconfig/autofs or
> auto.master options to the automount program.

I'm sure that the folks at RedHat will help us with this.

There's nothing atm but perhaps an environment variable to tell autofs 
whether to be lazy about updates. If I can just come up with a simple way 
to tell the process leader what it needs to do and, if only a record 
update, the key???

I'll think about it.

Ian

_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs

Reply via email to