Re: [Qemu-block] [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening

[Kevin Wolf]

Am 10.05.2016 um 10:50 hat Daniel P. Berrange geschrieben:
> On Tue, May 10, 2016 at 09:43:04AM +0100, Richard W.M. Jones wrote:
> > On Tue, May 10, 2016 at 09:14:26AM +0100, Richard W.M. Jones wrote:
> > > However I didn't test the write-shareable case (the libvirt
> > > <shareable/> flag which should map to a shared lock -- is that right 
> > > Dan?).
> > 
> > To Dan (mainly): I think setting the <shareable/> flag in libvirt only
> > sets cache=unsafe on the qemu drive (it may have other effects for
> > virtlockd).  Should there be an extra qemu drive flag to communicate
> > that the drive is write-shareable?
> 
> Sure, if QEMU had a way to indicate that the disk was used in a
> write-sharable mode, libvirt would use it.
> 
> I agree with your general point that we should do no locking for
> read-only access, F_RDLCK for shared-write and F_WRLCK for
> exclusive-write access. I think I made that point similarly against
> an earlier version of this patchset

Why should we do no locking for read-only access by default? If an image
is written to, read-only accesses are potentially inconsistent and we
should protect users against it.

The only argument I can see in the old versions of this series is
"libguestfs does it and usually it gets away with it". For me, that's
not an argument for generally allowing this, but at most for providing a
switch to bypass the locking.

Because let's be clear about this: If someone lost data because they
took an inconsistent backup this way and comes to us qemu developers,
all we can tell them is "sorry, what you did is not supported". And
that's a pretty strong sign that locking should prevent it by default.

Kevin