[Bug debuginfod/30221] Negative cache should differentiate failure types

["fche at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30221

--- Comment #6 from Frank Ch. Eigler <fche at redhat dot com> ---
(In reply to Vicki Pfau from comment #2)
> 404 and the like *may* be transient, but the fact of the matter is that
> *most* of the time it won't be And it's a cache, not a definitive answer
> saying this will never exist. Having a 404 cache for 10x the amount of time
> as a Ctrl-C

I don't understand - a ctrl-C should not result in a cached artifact at all.
If that's happening, we should fix that.

> I'm already dealing with gdb taking well
> over 30 seconds to start running a program with a bunch of shared object
> dependencies that aren't in debuginfod...

Uncached misses from debuginfod tend to take on the order of milliseconds,
much less than seconds.  Do you have a trace of what's happening?
(DEBUGINFOD_VERBOSE=1 or something like that?)

> [...] because there's no way for the cache to say "this probably won't
> appear in the short term." Setting cache_miss_s higher works, but is a
> workaround.

That workaround is precisely the parameter for the quantity you seek.

> Your filesystem representation works
> for the small, simple case you have here, but it won't scale if you try and
> extend the system with any metadata at all.

That's fine.  If we can revisit when rationale exists for more metadata.

-- 
You are receiving this mail because:
You are on the CC list for the bug.