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

[Doug Dumitru]

Mr. Assche,

Thank you for the link.  The proposal describes quite well "why"
multi-segment atomic writes are useful.  I am not sure that this proposal
actually made it into the SPC-5 spec.  It looks like it might overload some
of the data integrity fields and use them to link transactions together,
but I am rusty at reading specs like these.  I will re-read it again over
the weekend.  If anyone "knows" whether the multi-segment support is IN or
OUT of the SPC-5 spec, please chime in.

Doug




On Thu, Jul 9, 2015 at 10:24 AM, Bart Van Assche <bart.vanassche at sandisk.com
> wrote:

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


-- 
Doug Dumitru
EasyCo LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20150709/d07699f5/attachment.htm>