From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58193) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3SUq-0003xc-Il for qemu-devel@nongnu.org; Fri, 02 Mar 2012 08:26:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3SUk-0000fN-1B for qemu-devel@nongnu.org; Fri, 02 Mar 2012 08:26:08 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:64105) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3SUj-0000fC-OD for qemu-devel@nongnu.org; Fri, 02 Mar 2012 08:26:01 -0500 Received: by pbcuo5 with SMTP id uo5so1174074pbc.4 for ; Fri, 02 Mar 2012 05:25:59 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4F50CA60.4080500@redhat.com> Date: Fri, 02 Mar 2012 14:25:52 +0100 From: Paolo Bonzini 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> In-Reply-To: <4F50C47F.7070805@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: Kevin Wolf Cc: Federico Simoncelli , Eric Blake , qemu-devel@nongnu.org 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? Hmm, actually there could one problem. Say you switch from base->old to base->new; if old is the outcome of a live snapshot operation, base will still be open read-write. So perhaps we do need a new method like bdrv_freeze; after bdrv_freeze you know that bdrv_close will not need to write to disk. So e.g. for QED bdrv_freeze will turn off the need-check bit. Paolo