==> Regarding Re: [autofs] stat of /users/no-such-user takes 15 seconds; Ian 
Kent <[EMAIL PROTECTED]> adds:

raven> 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.

raven> 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 :(

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

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

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

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

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

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

Ian, the point here is that the map key isn't out of date.  We don't detect
that the entry didn't exist in the first place.  See my other post to this
thread, where I've attached a patch.  Comments on that are, of course,
encouraged.

-Jeff

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

Reply via email to