[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: Kevin Wolf
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 0/5] Auto-fragment large transactions at the block layer
Date: Tue, 21 Jun 2016 12:43:08 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 21.06.2016 um 12:23 hat Stefan Hajnoczi geschrieben:
> 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).
> I'm concerned that requests A & B which should be atomic can now be
> interleaved.

I don't think there is any guarantee of atomicity for overlapping
requests, at least not with more than a single sector (logical block
size, not BDRV_SECTOR_SIZE).

That is, as far as I know neither hardware nor the Linux kernel nor the
qemu block layer (image formats fragment all the time!) protect against
this. If you have concurrent overlapping requests, you always get
undefined behaviour.

> 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".

If we wanted to achieve this semantics, it would be easy enough: Add a
mark_request_serialising() in the right place. But I'm pretty sure that
this isn't needed.


Attachment: pgpOKixfMi6IS.pgp
Description: PGP signature

reply via email to

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