[dm-devel] API for multi-segment atomic IO

[Bart Van Assche]

On 07/09/2015 10:09 AM, Doug Dumitru wrote:
> The problem with this is that the SCSI commands do not go far enough to
> actually address the needs of applications that need atomic updates.  An
> application would "like" to be able to update a large arbitrary set, of
> sectors on a device with atomic semantics. The SCSI commands require the
> set to be contiguous.  Application design starts to get interesting when
> the contiguous restriction goes away.
>
> My initial thoughts are to tag multiple IO requests with an ID and
> combined length field.  This would be compatible with the SCSI spec if
> the request was contiguous, but nonsensical if the request were
> multi-segment.  On the other hand, just hitting the SCSI spec is
> probably as simple as adding an "atomic" bit to the current structure so
> that IO pieces are not cut up.  But then, you don't address the
> multi-segment functionality that is possible.  Regardless, there will be
> issues as pieces of the current stack don't lend themselves well to
> propagating atomic operations up and down the stack.  Just how do you
> split an atomic write across scsi devices in a raid set anyway?
>
> What I am most interested in is keeping the stack working with at least
> 1:1 mapping layers, and with 1:many layers below the layer that
> implements the atomic functionality.  Think of a dm-atomic.ko device
> that uses a log internally to implement multi-segment atomic writes.  It
> can talk safely to raid below it, but lvm should be able to sit above it
> and still have a file system that expects atomic functionality to work.
> Now getting a SAN connection to work like this would involve a new
> transport as iSCSI doesn't really have the semantics for this, but maybe
> there are some extra "transaction ID" bits that could be put into play
> (it has been a long time since I dug into the depths of the SCSI layers).

Hello Doug,

The original proposal, from which the SBC-4 ATOMIC WRITE specification 
has been derived, had support for scattered writes and gathered reads. 
The title of that document is "SBC-4 SPC-5 Atomic writes and reads" 
(http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-043r4.pdf).

Bart.