Re: [libvirt] [RFC PATCH 2/2] qemu: Force capabilities cache read if libvirtd date is different

On 05/20/2015 10:22 AM, Ján Tomko wrote: > s/read/refresh/ in the commit message? > > On Wed, May 20, 2015 at 08:52:57AM -0400, John Ferlan wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=1195882 >> >> Original commit id 'cbde3589' indicates that the cache file would be >> discarded if either the QEMU binary or libvirtd 'ctime' changes; however, >> the code only discarded if the QEMU binary time didn't match or if the >> new libvirtd ctime was later than what created the cache file. >> >> This could lead to issues with respect to how the order of libvirtd images >> is created for maintenance or patch branches where if someone had a libvirtd >> created on 'date x' that was created from (a) backported patch(es) followed >> by a subsequent install of the primary release which would have 'date y' >> where if 'date x' was greater than 'date y', then features in a primary >> release branch may not be available. > > I can see how here can be two daemons with different ctimes on the same > system during development, so ACK to the change. But they'd use different cache paths, right? > > However, when you install the daemon (even from an older package), ctime > should only move forward, so I'm sceptical about its relevance to the > referenced bug. Perhaps that my misinterpretation or misunderstanding of ctime - certainly in a different OS I used to work on many years ago - ctime was when the image was created by a build and not when the inode or file change time as I (now) read... So hmmm... that blows my theory to shreds - unless you account for that window of time during an install where files are being replaced while libvirtd is still running an older release. As Dan notes in my 1/2 removing the cache in between would be racey. So would it also be racey if something caused a cache read, code finds updated libvirtd, asks qemu for current capabilities, gets answer, creates file based on current (or old) understanding... Then when libvirtd restarts it finds a ctime of itself, doesn't update the cache, and of course doesn't have the latest bits.