On Fri, May 22, 2015 at 11:56:24AM +0200, Michal Privoznik wrote: > On 20.05.2015 19:35, John Ferlan wrote: > > > > > > 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. > > How about computing a hash of the qemu binary, and if hashes do not > equal recompile the cache? That would catch the unlikely case of someone moving the system time back and changing the QEMU binary at the exact time when the old one was changed. Jan
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list