[OpenAFS-devel] Re: freezes acessing /afs/.git

[Jeffrey Hutzelman]

On Fri, 2014-08-15 at 11:32 -0500, Andrew Deason wrote:
> On Fri, 15 Aug 2014 12:06:53 -0400
> Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
> 
> > FWIW, I really dislike the notion of caching DNS lookup results for a
> > time other than the time-to-live provided by the DNS.  If the problem
> > is looking for a top-level 'git' domain, then it ought to be solved
> > simply by obeying the 1-day TTL advertised by the root servers for
> > negative responses (this is the last number in the SOA record for the
> > root zone).
> 
> I don't think anything here prevents that. The kernel afsdb entries have
> a timeout entry, so that could always be recognized for negative
> entries... Though with how rarely a cell is added to DNS, it seems like
> a much more minor problem than the problem we're addressing. (I assume
> we'd have to query the SOA record ourselves separately? that's
> annoying.)

Oh, I should clarify.  When I said "it ought to be solved...", I meant
that obeying the TTL should make the problem go away.  I did not mean
that other approaches would not be acceptable.

A DNS query that results in an NXDOMAIN response will usually (always?)
include the relevant SOA record in its authority section.


> > That said, I think it may be a whole lot simpler to simply extend the
> > cache manager's existing cache to reflect the possibility of negative
> > entries.  The only real difficulty here is that such entries need
> > eventually to be removed, and I don't think we currently can ever
> > remove entries from the cell table.
> 
> I don't think you necessarily need to remove entries. Instead, an entry
> can just be repurposed for a newly-added entry (if we've hit some space
> limit). That gets a little harder of course if it's a hash table
> instead.
> 
> But also, to make it really simple we don't even necessarily need a hash
> table. Just using the dumb list that's there you could add negative
> entries and limit the number of negative entries to something small like
> 50, and any performance difference should not be noticeable.

Hm, so you never actually reclaim the memory, but there's a fixed upper
bound on how much can ever be allocated, and going beyond that may
result in older entries being pushed out prematurely?  That seems
reasonable to me.



> In particular, Markus did mention restricting no-dots entries, but that
> doesn't always work. He captured real examples of attempted accesses to
> things like latex .sty files, and one thing that even tried to load
> library files (/afs/libX11.so).

That sounds like a pretty serious misconfiguration.  And of course,
libX11.so is a perfectly legitimate cell name, if you happen to be
Somalia.

-- Jeff