From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NdQwp-0005hH-FG
	for qemu-devel@nongnu.org; Fri, 05 Feb 2010 11:22:23 -0500
Received: from [199.232.76.173] (port=49894 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NdQwp-0005h8-2t
	for qemu-devel@nongnu.org; Fri, 05 Feb 2010 11:22:23 -0500
Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim
	4.60) (envelope-from <hch@lst.de>) id 1NdQwl-0003N2-Dp
	for qemu-devel@nongnu.org; Fri, 05 Feb 2010 11:22:21 -0500
Received: from verein.lst.de ([213.95.11.210]:54866)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60)
	(envelope-from <hch@lst.de>) id 1NdQwk-0003LZ-8T
	for qemu-devel@nongnu.org; Fri, 05 Feb 2010 11:22:18 -0500
Date: Fri, 5 Feb 2010 17:22:15 +0100
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [PATCH 2/4] block: add block topology options
Message-ID: <20100205162215.GA24832@lst.de>
References: <20100129190417.GA25237@lst.de> <20100129190440.GA25287@lst.de>
	<4B69C7DF.9000900@codemonkey.ws> <20100205130956.GA17475@lst.de>
	<20100205161620.GB18601@shareable.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100205161620.GB18601@shareable.org>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jamie Lokier <jamie@shareable.org>
Cc: qemu-devel@nongnu.org, Christoph Hellwig <hch@lst.de>, "Martin K. Petersen" <martin.petersen@oracle.com>

On Fri, Feb 05, 2010 at 04:16:20PM +0000, Jamie Lokier wrote:
> If you move your VM to a new system with different backing devices,
> sometimes you want to be sure there is no guest-visible change.  Or
> even if you just replace a drive - you might prefer confidence that
> the guest sees no change.

Yes, that's why we do not auto probe it but require it to be set
manually.  Note that not the physical block size attribute can
we a data integrity issue, though.  A storage device guarnatees
that it can write a sector atomically, so moving from a 4k to a 512 byte
physcical sector device could lead to not beeing able to atomically
write a 4k piece of data that the guest expects to write atomcially.

I'm not sure how failure safe the read-modify-write algorithms on
4k sector disks with logical 512 bye blocks are, but I'd expect issues
there, too.

> Even if you just convert between qcow2 and a raw block device, or the
> other way, you'll sometimes want to be sure it's not guest-visible.

The image format has no hooks into these options currently.