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

["vi at endrift dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #7 from Vicki Pfau <vi at endrift dot com> ---
I have a proof of concept patch that I can attach here or submit to the mailing
list if you think the xattrs approach is a good way to go. Alternatively, a
metadata directory could be added under each buildid for per-file info, which
would work in the absence of functional xattrs, but be slightly more
complex.(In reply to Frank Ch. Eigler from comment #4)
> (In reply to Vicki Pfau from comment #3)
> > I have a proof of concept patch that I can attach here or submit to the
> > mailing list if you think the xattrs approach is a good way to go.
> > Alternatively, a metadata directory could be added under each buildid for
> > per-file info, which would work in the absence of functional xattrs, but be
> > slightly more complex.
> 
> Have you considered the idea of encoding the retention deadline in the
> boring inode mtime or ctime?

I did, and in comment 2 I already explained why I think it's a bad idea.(In
reply to Frank Ch. Eigler from comment #6)
> (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.

Okay, that is kinda weird then. I'm seeing it in gdb--perhaps it's a gdb issue
then.

> > 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?)

The issue appears to be the debuginfod server taking a not-insignificant amount
of time per request (500ms - 2s I'd estimate) to report the absence of an
associated artifact. Perhaps this is just an issue with how the server is
configured. I'm using the elfutils server, but I've seen the same issue on
Arch's server (the distro I'm using). It's worth noting too that some users
will undoubtedly have higher latency. A way to asynchronously initiate requests
so you can have multiple going at once would be great to try and alleviate this
somewhat, but it doesn't look like there's a way to do this yet.

> > [...] 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.

Assuming the Ctrl-C issue I mentioned above is resolved, you could well be
right. It's definitely the biggest source of the "transient" issues I
mentioned, though things like timeouts might still qualify.

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

Sounds good.

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