From: Kevin Wolf <kwolf@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: pbonzini@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com,
armbru@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH 00/19] block: Support for 512b-on-4k emulation
Date: Mon, 9 Dec 2013 14:02:46 +0100 [thread overview]
Message-ID: <20131209130246.GD3549@dhcp-200-207.str.redhat.com> (raw)
In-Reply-To: <20131209125148.GD9611@stefanha-thinkpad.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
prev parent reply other threads:[~2013-12-09 13:03 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-06 17:22 [Qemu-devel] [RFC PATCH 00/19] block: Support for 512b-on-4k emulation Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 01/19] qemu_memalign: Allow small alignments Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 02/19] block: Detect unaligned length in bdrv_qiov_is_aligned() Kevin Wolf
2013-12-06 19:12 ` Eric Blake
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 03/19] block: Don't use guest sector size for qemu_blockalign() Kevin Wolf
2013-12-10 3:18 ` Wenchao Xia
2013-12-10 9:42 ` Kevin Wolf
2013-12-11 2:43 ` Wenchao Xia
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 04/19] block: rename buffer_alignment to guest_block_size Kevin Wolf
2013-12-10 3:25 ` Wenchao Xia
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 05/19] raw: Probe required direct I/O alignment Kevin Wolf
2013-12-06 17:53 ` Paolo Bonzini
2013-12-09 12:58 ` Kevin Wolf
2013-12-09 13:40 ` Paolo Bonzini
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 06/19] block: Introduce bdrv_aligned_preadv() Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 07/19] block: Introduce bdrv_co_do_preadv() Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 08/19] block: Introduce bdrv_aligned_pwritev() Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 09/19] block: write: Handle COR dependency after I/O throttling Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 10/19] block: Introduce bdrv_co_do_pwritev() Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 11/19] block: Switch BdrvTrackedRequest to byte granularity Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 12/19] block: Allow waiting for overlapping requests between begin/end Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 13/19] block: Make zero-after-EOF work with larger alignment Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 14/19] block: Generalise and optimise COR serialisation Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 15/19] block: Make overlap range for serialisation dynamic Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 16/19] block: Align requests in bdrv_co_do_pwritev() Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 17/19] block: Change coroutine wrapper to byte granularity Kevin Wolf
2013-12-06 17:22 ` [Qemu-devel] [RFC PATCH 18/19] block: Make bdrv_pread() a bdrv_prwv_co() wrapper Kevin Wolf
2013-12-06 17:23 ` [Qemu-devel] [RFC PATCH 19/19] block: Make bdrv_pwrite() " Kevin Wolf
2013-12-06 17:55 ` [Qemu-devel] [RFC PATCH 00/19] block: Support for 512b-on-4k emulation Paolo Bonzini
2013-12-09 11:16 ` Kevin Wolf
2013-12-09 12:51 ` Stefan Hajnoczi
2013-12-09 13:02 ` Kevin Wolf [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131209130246.GD3549@dhcp-200-207.str.redhat.com \
--to=kwolf@redhat.com \
--cc=armbru@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).