From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55553) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq0UA-0000MZ-2c for qemu-devel@nongnu.org; Mon, 09 Dec 2013 08:03:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vq0U4-0008Ai-40 for qemu-devel@nongnu.org; Mon, 09 Dec 2013 08:02:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:61278) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq0U3-0008AS-Oz for qemu-devel@nongnu.org; Mon, 09 Dec 2013 08:02:48 -0500 Date: Mon, 9 Dec 2013 14:02:46 +0100 From: Kevin Wolf Message-ID: <20131209130246.GD3549@dhcp-200-207.str.redhat.com> References: <1386350580-5666-1-git-send-email-kwolf@redhat.com> <20131209125148.GD9611@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131209125148.GD9611@stefanha-thinkpad.redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH 00/19] block: Support for 512b-on-4k emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, armbru@redhat.com Am 09.12.2013 um 13:51 hat Stefan Hajnoczi geschrieben: > On Fri, Dec 06, 2013 at 06:22:41PM +0100, Kevin Wolf wrote: > > This series does not cover 4k guests on a 512 byte host, and I'm not > > sure yet what to do with this case. Paolos series contained a patch to > > protect against "torn reads" (i.e. reads running in parallel with > > writes, which return old data for one half of a sector and new data for > > the other half) by serialising requests if the guest block size was > > greater than the host block size. > > > > One problem with this approach is that it assumes that a single host > > block size even exists and can be compared against on the top level. > > Different backing files can be stored on different storage, though, with > > different block sizes. > > As long as the backing file is read-only you won't get torn reads. Right. Even with image fleecing you might get away with it, because you don't have an expected alignment on the NBD client (or do you?) But how about VMDK extents or Quorum backends, then? Kevin