[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] HMP: snapshot_blkdev can not consider //root/sn
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH] HMP: snapshot_blkdev can not consider //root/sn1 and /root/sn1 as the same file |
Date: |
Thu, 02 Jan 2014 06:06:26 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 |
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