From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3E1CA385559F; Fri, 17 Mar 2023 01:28:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3E1CA385559F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1679016535; bh=jZR2Marxktfe6XbgAti17PVcP7SdkT57910eXgw3ONk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=vJk6ut1gFa20t8+yImcruheRBzr/F2/4YnceSYuT/t9gRvp6kZC90GFDHz2qnTe5J 3g9gTjDU9yDVERxM/2TTdn+kzBSm61+IsDISMpuf5O+QilG7Rg5HTetzCz90azxHpq QMQIUWs5L/DwBOi9SZmtPL8zNt82Wwu1yA9bY2Os= From: "vi at endrift dot com" To: elfutils-devel@sourceware.org Subject: [Bug debuginfod/30221] Negative cache should differentiate failure types Date: Fri, 17 Mar 2023 01:28:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: elfutils X-Bugzilla-Component: debuginfod X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vi at endrift dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30221 --- Comment #7 from Vicki Pfau --- I have a proof of concept patch that I can attach here or submit to the mai= ling 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, whi= ch 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 f= or > > per-file info, which would work in the absence of functional xattrs, bu= t be > > slightly more complex. >=20 > 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 >=20 > I don't understand - a ctrl-C should not result in a cached artifact at a= ll. > 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 is= sue 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... >=20 > 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=3D1 or something like that?) The issue appears to be the debuginfod server taking a not-insignificant am= ount 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 requ= ests 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. >=20 > 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. >=20 > That's fine. If we can revisit when rationale exists for more metadata. Sounds good. --=20 You are receiving this mail because: You are on the CC list for the bug.=