From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:37235)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1S3S3f-0007yf-8J
	for qemu-devel@nongnu.org; Fri, 02 Mar 2012 07:58:35 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1S3S2y-0003iA-L8
	for qemu-devel@nongnu.org; Fri, 02 Mar 2012 07:58:02 -0500
Received: from mx1.redhat.com ([209.132.183.28]:5345)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1S3S2y-0003hx-Cw
	for qemu-devel@nongnu.org; Fri, 02 Mar 2012 07:57:20 -0500
Received: from int-mx11.intmail.prod.int.phx2.redhat.com
	(int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q22CvICX023112
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <qemu-devel@nongnu.org>; Fri, 2 Mar 2012 07:57:19 -0500
Message-ID: <4F50C47F.7070805@redhat.com>
Date: Fri, 02 Mar 2012 14:00:47 +0100
From: Kevin Wolf <kwolf@redhat.com>
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>
In-Reply-To: <4F4FA93D.9020200@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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Federico Simoncelli <fsimonce@redhat.com>, Eric Blake <eblake@redhat.com>, qemu-devel@nongnu.org

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.

Kevin