On Tue, 2013-06-18 at 10:46 -0400, Zdenek Pavlas wrote: > > "/version" cache mostly useless (it's always generated within the same > > second that we last altered the rpmdb AFAIK). > > Likely. But the next rpmdb access saves /version with new > timestamp so THEN it's cached.
Yeh, but there's only 1 hit/miss a lot of the time. Eg. user runs: 1. yum install foo 2. yum install bar ...here we either load the cached data (from the end of #1) at #2, or we miss and act as if the cache didn't exist. I don't even think yum-cron regenerates the caches, although it should. > Still, we unnecessarily give > up one cache hit (on a fs with 1s mtime precision). Yeh, there is that ... apart from (apparently) nokia phones I'm not sure who is really using an fs != ext4 or xfs anymore. AIUI it's not even an option soon (maybe already) and you have to run ext4 with features turned off to get the same behaviour (I assume mtime resolution isn't one of the configurable options). But that works the other way too, it's basically impossible to trigger the bug without 1s resolution and you have to do something pretty stupid to trigger it (run+complete a direct rpm transaction within a second after yum finishes). So, again, I'm heavily inclined to just say "stop doing that" unless we really need to come up with some workaround. _______________________________________________ Yum-devel mailing list [email protected] http://lists.baseurl.org/mailman/listinfo/yum-devel
