[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH 0/5] Auto-fragment large transactio

From: Stefan Hajnoczi
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 0/5] Auto-fragment large transactions at the block layer
Date: Tue, 21 Jun 2016 11:23:57 +0100
User-agent: Mutt/1.6.1 (2016-04-27)

On Mon, Jun 20, 2016 at 05:39:24PM -0600, Eric Blake wrote:
> We have max_transfer documented in BlockLimits, but while we
> honor it during pwrite_zeroes, we were blindly ignoring it
> during pwritev and preadv, leading to multiple drivers having
> to implement fragmentation themselves.  This series moves
> fragmentation to the block layer, then fixes the NBD driver to
> use it; if you like this but it needs a v2, you can request that
> I further do other drivers (I know at least iscsi and qcow2 do
> some self-fragmenting and/or error reporting that can be
> simplified by deferring fragmentation to the block layer).
> Prequisite: Kevin's block branch, plus my work on byte-based
> block limits (v2 at the moment):
> https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg04006.html
> Also available as a tag at:
> git fetch git://repo.or.cz/qemu/ericb.git nbd-fragment-v1
> Eric Blake (5):
>   block: Fragment reads to max transfer length
>   block: Fragment writes to max transfer length
>   raw_bsd: Don't advertise flags not supported by protocol layer
>   nbd: Rely on block layer to break up large requests
>   nbd: Drop unused offset parameter
>  include/block/nbd.h |  1 -
>  nbd/nbd-internal.h  |  4 +--
>  block/io.c          | 84 
> +++++++++++++++++++++++++++++++++++++++--------------
>  block/nbd-client.c  | 78 ++++++++++++++-----------------------------------
>  block/nbd.c         | 12 ++------
>  block/raw_bsd.c     |  6 ++--
>  nbd/common.c        |  3 +-
>  7 files changed, 95 insertions(+), 93 deletions(-)

I'm concerned that requests A & B which should be atomic can now be

For example, two writes that are overlapping and fragmented.
Applications expect to either see A or B on disk when both requests have
completed.  Fragmentation must serialize overlapping requests in order
to prevent interleaved results where the application sees some of A and
some of B when both requests have completed.

A similar scenario happens when A is a read and B is a write, too.  Read
A is supposed to see either "before B" or "after B".  With fragmentation
it can see "some of before B and some of after B".

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]