From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3Se0-0005xX-6u for qemu-devel@nongnu.org; Fri, 02 Mar 2012 08:35:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3Sda-0002Cn-Hn for qemu-devel@nongnu.org; Fri, 02 Mar 2012 08:35:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:18126) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3Sda-0002Ci-9r for qemu-devel@nongnu.org; Fri, 02 Mar 2012 08:35:10 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q22DZ80C028031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 2 Mar 2012 08:35:08 -0500 Message-ID: <4F50CD5D.8030507@redhat.com> Date: Fri, 02 Mar 2012 14:38:37 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <1330614819-26929-1-git-send-email-fsimonce@redhat.com> <4F4F977B.3020504@redhat.com> <4F4FA284.40400@redhat.com> <4F4FA93D.9020200@redhat.com> <4F50C47F.7070805@redhat.com> <4F50CA60.4080500@redhat.com> In-Reply-To: <4F50CA60.4080500@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] add reopen to blockdev-transaction List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Federico Simoncelli , Eric Blake , qemu-devel@nongnu.org Am 02.03.2012 14:25, schrieb Paolo Bonzini: > Il 02/03/2012 14:00, Kevin Wolf ha scritto: >> Am 01.03.2012 17:52, schrieb Paolo Bonzini: >>>>> But you can even keep from your first patch the drive-reopen command and >>>>> not make it atomic, that shouldn't be a problem. >>>> >>>> I'm not sure whether it makes sense for a separate drive-reopen or >>>> whether to just add this to blockdev-transaction (or even both); I can >>>> make libvirt use whichever color bikeshed we pick. There's definitely a >>>> transaction aspect here >>> >>> It's not so much atomicity, it's just safety. The drive-reopen command >>> must be implemented in a similar way to bdrv_append; it must not do a >>> close+reopen in the same way as the existing blockdev-snapshot-sync >>> command, but that's just that blockdev-snapshot-sync was implemented >>> poorly. >> >> For reopen this is a bit harder because you deal with already opened >> images and you must never have the same image opened twice at the same time. > > This is only for read-write images, and the backing files are read-only, > so this shouldn't be a problem, no? Opening an image read-write that is still open read-only may break the read-only instance. You can argue that opening an image read-only while a read-write instance is open can be tolerated if you flushed the image and made sure no new requests are coming in. This is what happens with live migration. It's a case that has given us enough headaches that I would not want to introduce similar behaviour in more cases. So in short: Regardless of ro/rw, opening images twice is bad. Just don't do it. If anything, a possible solution could look like the bdrv_reopen proposal which already includes prepare/commit/abort functions in the block driver. Kevin