<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Mr. Assche,<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">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.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Doug<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 9, 2015 at 10:24 AM, Bart Van Assche <span dir="ltr"><<a href="mailto:bart.vanassche@sandisk.com" target="_blank">bart.vanassche@sandisk.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 07/09/2015 10:09 AM, Doug Dumitru wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The problem with this is that the SCSI commands do not go far enough to<br>
actually address the needs of applications that need atomic updates.  An<br>
application would "like" to be able to update a large arbitrary set, of<br>
sectors on a device with atomic semantics. The SCSI commands require the<br>
set to be contiguous.  Application design starts to get interesting when<br>
the contiguous restriction goes away.<br>
<br>
My initial thoughts are to tag multiple IO requests with an ID and<br>
combined length field.  This would be compatible with the SCSI spec if<br>
the request was contiguous, but nonsensical if the request were<br>
multi-segment.  On the other hand, just hitting the SCSI spec is<br>
probably as simple as adding an "atomic" bit to the current structure so<br>
that IO pieces are not cut up.  But then, you don't address the<br>
multi-segment functionality that is possible.  Regardless, there will be<br>
issues as pieces of the current stack don't lend themselves well to<br>
propagating atomic operations up and down the stack.  Just how do you<br>
split an atomic write across scsi devices in a raid set anyway?<br>
<br>
What I am most interested in is keeping the stack working with at least<br>
1:1 mapping layers, and with 1:many layers below the layer that<br>
implements the atomic functionality.  Think of a dm-atomic.ko device<br>
that uses a log internally to implement multi-segment atomic writes.  It<br>
can talk safely to raid below it, but lvm should be able to sit above it<br>
and still have a file system that expects atomic functionality to work.<br>
Now getting a SAN connection to work like this would involve a new<br>
transport as iSCSI doesn't really have the semantics for this, but maybe<br>
there are some extra "transaction ID" bits that could be put into play<br>
(it has been a long time since I dug into the depths of the SCSI layers).<br>
</blockquote>
<br></div></div>
Hello Doug,<br>
<br>
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" (<a href="http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-043r4.pdf" rel="noreferrer" target="_blank">http://www.t10.org/cgi-bin/ac.pl?t=d&f=14-043r4.pdf</a>).<span class="HOEnZb"><font color="#888888"><br>
<br>
Bart.<br>
<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Doug Dumitru<br>EasyCo LLC<br></div>
</div>