From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52913) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIrez-0002O2-LV for qemu-devel@nongnu.org; Tue, 12 Jan 2016 00:38:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIrew-0007mr-Fu for qemu-devel@nongnu.org; Tue, 12 Jan 2016 00:38:25 -0500 Received: from relay.parallels.com ([195.214.232.42]:36693) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIrew-0007me-7g for qemu-devel@nongnu.org; Tue, 12 Jan 2016 00:38:22 -0500 References: <567A4EB0.1040807@parallels.com> <1450856816-9816-1-git-send-email-den@openvz.org> <1450856816-9816-2-git-send-email-den@openvz.org> <20160111173106.GL9454@noname.redhat.com> From: "Denis V. Lunev" Message-ID: <56949140.1010800@openvz.org> Date: Tue, 12 Jan 2016 08:38:08 +0300 MIME-Version: 1.0 In-Reply-To: <20160111173106.GL9454@noname.redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/5] block: added lock image option and callback List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Fam Zheng , Olga Krishtal , qemu-devel@nongnu.org, Max Reitz On 01/11/2016 08:31 PM, Kevin Wolf wrote: > Am 23.12.2015 um 08:46 hat Denis V. Lunev geschrieben: >> From: Olga Krishtal >> >> While opening the image we want to be sure that we are the >> one who works with image, anf if it is not true - >> opening the image for writing should fail. >> >> There are 2 ways at the moment: no lock at all and lock the file >> image. >> >> Signed-off-by: Olga Krishtal >> Signed-off-by: Denis V. Lunev >> CC: Kevin Wolf >> CC: Max Reitz >> CC: Eric Blake >> CC: Fam Zheng > As long as locking is disabled by default, it's useless and won't > prevent people from corrupting their images. These corruptions happen > exactly because people don't know how to use qemu properly. You can't > expect them to enable locking manually. You are right. Though this is not a big problem to enable locking. If there are several mechanics, we could save one into the qcow2 header. > Also, you probably need to consider bdrv_reopen() and live migration. > I think live migration would be blocked if source and destination both > see the lock; which is admittedly less likely than with the qcow2 patch > (and generally a problem of this series), but with localhost migration > and potentially with some NFS setups it can be the case. > > Kevin for live migration the situation should be not that problematic. The disk is opened in RW mode only on one node. Am I right? The lock is taken when the image is opened in RW mode only. Den