On 01/02/2014 01:55 AM, Stefan Hajnoczi wrote: > Okay, I think we got side-tracked worrying about identifying identical > files. The problem in your example is more fundamental. > > Here is what should have happened: > > (qemu) snapshot_blkdev drive-scsi0-0-0 /mnt/dir2/sn1 > Could not create '/mnt/dir2/sn1': File exists > > The file was previously created with the name /mnt/dir1/sn1. Running > snapshot_blkdev with /mnt/dir2/sn1 clobbers the file in your example. > This is bad because it corrupts the backing chain. > > If QEMU uses O_CREAT | O_EXCL open(2) flags then creating the snapshot > file fails and the user will not mistakingly overwrite sn1. > > However, QEMU does not use O_EXCL to create image files anywhere today > (qemu-img or QEMU monitor commands). Returning an error is not > backwards-compatible since existing users might rely on clobbering files > (there are safe cases where it can be useful).
In fact, libvirt _requires_ that you clobber existing image files - when libvirt drives qemu with SELinux labelling enabled, then qemu cannot create files, but can only open already existing files that have already been labelled. So libvirt would need a way to avoid O_EXCL, even if you add it and make it default (and if you change the default to O_EXCL, you also need to provide a way to probe for the new switch that can bypass that new default). > > We could add an option to commands that create files but I'm not sure if > it's worth the effort since human users who are most at risk probably > won't provide this new option... Changing to be safe by default and requiring a new option to allow reuse of existing files might be okay; but it will be backwards incompatible. Keeping existing behavior and requiring a new option to turn on O_EXCL for safety is back-compat friendly, but is the very situation where users aren't going to know they need to use the new option, so you've gained no safety. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
