From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50917) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqGxY-0003Gt-Lk for qemu-devel@nongnu.org; Wed, 13 Apr 2016 05:19:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqGxX-0004Rj-Hn for qemu-devel@nongnu.org; Wed, 13 Apr 2016 05:19:40 -0400 Date: Wed, 13 Apr 2016 10:19:29 +0100 From: "Daniel P. Berrange" Message-ID: <20160413091929.GC8847@redhat.com> Reply-To: "Daniel P. Berrange" References: <1460538604-12132-1-git-send-email-famz@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1460538604-12132-1-git-send-email-famz@redhat.com> Subject: Re: [Qemu-devel] [PATCH for-2.7 00/15] block: Lock images when opening List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: qemu-devel@nongnu.org, Kevin Wolf , Max Reitz , Jeff Cody , Markus Armbruster , Eric Blake , John Snow , qemu-block@nongnu.org, pbonzini@redhat.com, den@openvz.org On Wed, Apr 13, 2016 at 05:09:49PM +0800, Fam Zheng wrote: > Too many troubles have been caused by two processes writing to the same image > unexpectedly. This series introduces automatical image locking into QEMU to > avoid such tragedy. With this, the user won't be able to open the image from > two processes (e.g. using qemu-img when the image is attached to the guest). > > Underneath is the fcntl syscall that locks the local file, similar to what is > already used in libvirt virtlockd. Also because of that, we cannot directly > apply fcntl lock on the image file itself, instead we open and lock > "/var/tmp/.qemu-$sha1.lock", where $sha1 is derived from the image's full path > as in realpath(3). This mechanism should be equally useful for the single host > case, and it doesn't conflict with virtlockd when managed by libvirt. > > The alternative file locking API on Linux, flock(2), cannot protect host NFS > mount points, so it's not used. Maybe I'm missing something, but since you are locking /var/tmp/.qemu-$sha1.lock the question of NFS support is irrelevant. All your locks are only ever going to apply within the local host, since /var/tmp is always a local filesystem, regardless of whether the actual image is on NFS. IOW, even using fcntl() you have no cross-host protection for NFS based images here. BTW, looking again at the virtlockd code I notice that I had the good idea to be very selective with our use of fcntl() - rather than locking the entire file, we only lock a single byte at offset 0. So it would be possible for QEMU to directly using fcntl() on the image file, if it provided a non-zero offset to lock at. eg QEMU could lock byte 1 and that shouldn't interact with virtlockd's lock at byte 0. 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 :|