From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37584) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBdxS-0001bz-Uh for qemu-devel@nongnu.org; Wed, 23 Dec 2015 02:35:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBdxO-0003d2-TX for qemu-devel@nongnu.org; Wed, 23 Dec 2015 02:35:38 -0500 Received: from relay.parallels.com ([195.214.232.42]:59649) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBdxO-0003aR-Lt for qemu-devel@nongnu.org; Wed, 23 Dec 2015 02:35:34 -0500 References: <1450802786-20893-1-git-send-email-kwolf@redhat.com> <20151223031412.GC14423@ad.usersys.redhat.com> From: "Denis V. Lunev" Message-ID: <567A4EB0.1040807@parallels.com> Date: Wed, 23 Dec 2015 10:35:12 +0300 MIME-Version: 1.0 In-Reply-To: <20151223031412.GC14423@ad.usersys.redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 00/10] qcow2: Implement image locking List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , Kevin Wolf Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, mreitz@redhat.com On 12/23/2015 06:14 AM, Fam Zheng wrote: > On Tue, 12/22 17:46, Kevin Wolf wrote: >> Enough innocent images have died because users called 'qemu-img snapshot' while >> the VM was still running. Educating the users doesn't seem to be a working >> strategy, so this series adds locking to qcow2 that refuses to access the image >> read-write from two processes. >> >> Eric, this will require a libvirt update to deal with qemu crashes which leave >> locked images behind. The simplest thinkable way would be to unconditionally >> override the lock in libvirt whenever the option is present. In that case, >> libvirt VMs would be protected against concurrent non-libvirt accesses, but not >> the other way round. If you want more than that, libvirt would have to check >> somehow if it was its own VM that used the image and left the lock behind. I >> imagine that can't be too hard either. > The motivation is great, but I'm not sure I like the side-effect that an > unclean shutdown will require a "forced" open, because it makes using qcow2 in > development cumbersome, and like you said, management/user also needs to handle > this explicitly. This is a bit of a personal preference, but it's strong enough > that I want to speak up. > > As an alternative, can we introduce .bdrv_flock() in protocol drivers, with > similar semantics to flock(2) or lockf(3)? That way all formats can benefit, > and a program crash will automatically drop the lock. > > Fam Exactly! I have a set in progress for this purpose. In this case we will be able to automatically recover from crash (with a lock taken) calling bdrv_check. Den