qemu-block
[Top][All Lists]
Advanced

[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: Wed, 22 Jun 2016 12:41:19 +0100
User-agent: Mutt/1.6.1 (2016-04-27)

On Tue, Jun 21, 2016 at 12:43:08PM +0200, Kevin Wolf wrote:
> 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.

Kevin, I think you are right and my mental model was wrong.

I spent some time looking at SCSI SAM and SBC documents.  The closest
information I found was SBC "4.27 Model for uninterrupted sequences on LBA
ranges" where ORWRITE, XDWRITEREAD, XPWRITE, and COMPARE AND WRITE are
singled out.  It implies that the device server may access LBAs while
other types of commands are executing.

If anyone knows a better reference in the SCSI specifications that
clarifies behavior of overlapping I/O requests, please share!

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

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