public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: "vi at endrift dot com" <sourceware-bugzilla@sourceware.org>
To: elfutils-devel@sourceware.org
Subject: [Bug debuginfod/30221] Negative cache should differentiate failure types
Date: Tue, 14 Mar 2023 01:47:28 +0000	[thread overview]
Message-ID: <bug-30221-10460-bacfzwlUGP@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-30221-10460@http.sourceware.org/bugzilla/>

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

--- Comment #2 from Vicki Pfau <vi at endrift dot com> ---
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
would be a benefit to users 99% of the time, if not more. You don't need to
overgeneralize to a surefire 100% of the time for something that's already
"soft" like a cache. 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...only to have to do that again in 10 minutes 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.

Using an artificial timestamp to fake out the cache_miss_s expiry is a hack.
There's no other way of describing it. You're trying to wedge down additional
information to a dumber system instead of making the system smarter if you go
for that approach. 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. You have one inode per negative cache file instead of one
entry in, e.g. a SQLite database, which you can add additional columns to.
xattrs are still a bit of a kludge but at least aren't trying to spoof
information to fool a system unaware of complexity existing.

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

  parent reply	other threads:[~2023-03-14  1:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-11  1:32 [Bug debuginfod/30221] New: " vi at endrift dot com
2023-03-13 16:40 ` [Bug debuginfod/30221] " fche at redhat dot com
2023-03-14  1:47 ` vi at endrift dot com [this message]
2023-03-17  1:00 ` vi at endrift dot com
2023-03-17  1:08 ` fche at redhat dot com
2023-03-17  1:16 ` vi at endrift dot com
2023-03-17  1:20 ` fche at redhat dot com
2023-03-17  1:28 ` vi at endrift dot com
2023-03-17  1:30 ` vi at endrift dot com
2023-03-17 16:16 ` amerey at redhat dot com
2023-03-17 16:53 ` amerey at redhat dot com
2023-03-17 23:39 ` vi at endrift dot com
2023-03-24 11:22 ` fche at redhat dot com
2023-04-08 13:29 ` mark at klomp dot org
2023-04-21  2:04 ` fche at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-30221-10460-bacfzwlUGP@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=elfutils-devel@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).