From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58286) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bywkb-0001lR-Eo for qemu-devel@nongnu.org; Tue, 25 Oct 2016 04:06:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bywka-0000u0-IX for qemu-devel@nongnu.org; Tue, 25 Oct 2016 04:06:25 -0400 Date: Tue, 25 Oct 2016 09:06:15 +0100 From: "Richard W.M. Jones" Message-ID: <20161025080615.GV11243@redhat.com> References: <1475237406-26917-1-git-send-email-famz@redhat.com> <20161024101111.GB4374@noname.redhat.com> <20161025070951.GF5427@lemon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161025070951.GF5427@lemon> Subject: Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: Kevin Wolf , Max Reitz , qemu-devel@nongnu.org, berrange@redhat.com, John Snow , qemu-block@nongnu.org, Jeff Cody , Markus Armbruster , stefanha@redhat.com, den@openvz.org, pbonzini@redhat.com, eblake@redhat.com On Tue, Oct 25, 2016 at 03:09:51PM +0800, Fam Zheng wrote: > On Mon, 10/24 12:11, Kevin Wolf wrote: > > Am 22.10.2016 um 03:00 hat Max Reitz geschrieben: > > > > > > > > > I personally still don't like making locking a qdev property very much > > > because it doesn't make sense to me*. But I remember Kevin had his > > > reasons (even though I can no longer remember them) for asking for it, > > > and I don't have any besides "It doesn't make sense to me". After having > > > though a bit about it (= having written three paragraphs and deleted > > > them again), I guess I can make some sense of it, though it seems to be > > > a rather esoteric use case still; it appears to me that a guest could > > > use it to signal that it's fine with some block device being shared; > > > then we could use a shared lock or none at all or I don't know. > > > Otherwise, we should get an exclusive lock for write access and a shared > > > lock for read access. > > > > The reason is pretty simple if you think about this question: Why do we > > need user input in the first place? > > I think the reason why we have an option at all is rather because of the special > case of libguestfs [1], otherwise locks should just be acquired sensibly as the > "auto" mode does. It's not just that. Qemu doesn't have enough information to make the correct decision about locking automatically -- for example, Qemu doesn't know if the guest is using cluster filesystems or not (or for some other reason the guest wants a shared writable block device, eg. for running Disk Paxos). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html