[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: |
Eric Blake |
Subject: |
Re: [Qemu-block] [Qemu-devel] [PATCH 0/5] Auto-fragment large transactions at the block layer |
Date: |
Tue, 21 Jun 2016 16:05:22 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 |
On 06/21/2016 04:23 AM, Stefan Hajnoczi wrote:
> 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.
>
> 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".
This patch series doesn't change that, it just changes where the
atomicity is broken. Consider that pre-patch, a raw format wrapping an
NBD protocol connection would see a 32M max_transfer, but we were not
fragmenting at the raw protocol. Thus, if someone requests a 40M
operation, the raw protocol treats it as a single transaction, and NBD
then fragments it into two transactions over the wire; and NBD can
complete transactions out of order. All this series does is move the
fragmentation to the raw layer, rather than the NBD layer, but the race
between overlapping oversize requests is present whether or not the
series is applied.
>
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- [Qemu-block] [PATCH 1/5] block: Fragment reads to max transfer length, (continued)
- [Qemu-block] [PATCH 1/5] block: Fragment reads to max transfer length, Eric Blake, 2016/06/20
- [Qemu-block] [PATCH 3/5] raw_bsd: Don't advertise flags not supported by protocol layer, Eric Blake, 2016/06/20
- [Qemu-block] [PATCH 5/5] nbd: Drop unused offset parameter, Eric Blake, 2016/06/20
- [Qemu-block] [PATCH 2/5] block: Fragment writes to max transfer length, Eric Blake, 2016/06/20
- [Qemu-block] [PATCH 4/5] nbd: Rely on block layer to break up large requests, Eric Blake, 2016/06/20
- [Qemu-block] [PATCH 6/5] iscsi: Rely on block layer to break up large requests, Eric Blake, 2016/06/20
- Re: [Qemu-block] [Qemu-devel] [PATCH 0/5] Auto-fragment large transactions at the block layer, Eric Blake, 2016/06/21
- Re: [Qemu-block] [Qemu-devel] [PATCH 0/5] Auto-fragment large transactions at the block layer, Stefan Hajnoczi, 2016/06/21
- Re: [Qemu-block] [Qemu-devel] [PATCH 0/5] Auto-fragment large transactions at the block layer, Fam Zheng, 2016/06/22