[OpenAFS] Re: freezes acessing /afs/.git
chas williams - CONTRACTOR
Thu, 14 Aug 2014 08:45:16 -0400
On Wed, 13 Aug 2014 22:26:36 -0500
Andrew Deason <firstname.lastname@example.org> wrote:
> This generally sounds reasonable to me. But I think you want to just
> require a dot if the name doesn't exist in the csdb at all, so you can
> just put it in the local csdb if you want to use it, without needing to
> alias it to a full cell name. (This may have been mentioned earlier, but
> I don't see it here.) I'd call such an option -afsdb-ndots, which would
> set the minimum number of dots (like resolv.conf's "option ndots").
I would probably prefer to have a whitelist of some sort that would
support regular expressions. You could then do something stupid like
require entries to have atleast a single . and end in one of the more
common domain suffixes.
> However, this doesn't solve the issue when files like libX11.so or
> beamer.cls like in your captured list. You really need a blacklist for
> these, or we can just try to improve the negative caching. iirc, we
After looking at the code, I think negative caching would be a big
win. When a lookup fails, it has to fail about 5 times: once to reset
the resolver and then 4 times for the each possible search.
> already have some hard-coded 'blacklist' entries to appease things like
> OS X's Finder, so a configurable blacklist doesn't seem like such a big
> change. Doing any actual pattern matching could be done in userspace and
> can be very slow if we just cache results in the kernel (keep a
> 'negative' cell struct around).
Keeping the negative cache in the kernel possibly isn't a good idea.
At a minimum you would need to bound the size. I don't think the
call up to afsd is that slow but if it is it could be fixed.
> A blacklist might help for a vast majority of cases, though. Or of
> course we could just improve the caching, so only the first lookup is
> slow... would that be good enough, if done "well"?
Very possibly given the way lookups have to happen to support all the
possible DNS records that might be out there.