[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening |
Date: |
Tue, 10 May 2016 10:23:38 +0100 |
User-agent: |
Mutt/1.6.0 (2016-04-01) |
On Tue, May 10, 2016 at 11:14:22AM +0200, Kevin Wolf wrote:
> 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.
We have 3 usage scenarios - readonly-share, writable-shared and
writable-exclusive, and only 2 lock types to play with. This series
does no locking at all in the writable-shared case, so we still have
the problem you describe in that someone opening the image for readonly
access will succeeed even when it is used writable-shared by another
process.
So we have to pick a trade-off here. IMHO it is more important to
ensure we have locks in both the write-shared & write-exclusive case,
as both of those can definitely result in corrupted images if not
careful, where as read-only access merely results in your reading
bad data, no risk of corrupting the original image.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
- [Qemu-devel] [PATCH v4 24/27] iotests: Disable image locking in 085, (continued)
- [Qemu-devel] [PATCH v4 24/27] iotests: Disable image locking in 085, Fam Zheng, 2016/05/09
- [Qemu-devel] [PATCH v4 21/27] qemu-iotests: Wait for QEMU processes before checking image in 091, Fam Zheng, 2016/05/09
- [Qemu-devel] [PATCH v4 23/27] iotests: 087: Disable image lock in cases where file is shared, Fam Zheng, 2016/05/09
- [Qemu-devel] [PATCH v4 26/27] block: Turn on image locking by default, Fam Zheng, 2016/05/09
- [Qemu-devel] [PATCH v4 25/27] tests: Use null-co:// instead of /dev/null, Fam Zheng, 2016/05/09
- [Qemu-devel] [PATCH v4 27/27] qemu-iotests: Add test case 153 for image locking, Fam Zheng, 2016/05/09
- Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening, Richard W.M. Jones, 2016/05/10
- Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening, Richard W.M. Jones, 2016/05/10
- Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening, Daniel P. Berrange, 2016/05/10
- Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening, Kevin Wolf, 2016/05/10
- Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening,
Daniel P. Berrange <=
- Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening, Kevin Wolf, 2016/05/10
- Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening, Daniel P. Berrange, 2016/05/10
- Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening, Kevin Wolf, 2016/05/10
- Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening, Richard W.M. Jones, 2016/05/10
- Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening, Kevin Wolf, 2016/05/10
- Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening, Richard W.M. Jones, 2016/05/10
- Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening, Kevin Wolf, 2016/05/10
- Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening, Richard W.M. Jones, 2016/05/10
- Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening, Daniel P. Berrange, 2016/05/10
- Re: [Qemu-devel] [PATCH v4 00/27] block: Lock images when opening, Kevin Wolf, 2016/05/10