<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 T10 links.  I was actually looking for something at a different level.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">I have a "smart" block device that can implement multi-segment atomic writes.  This is more than what T10 envisions in that the writes can span multiple LBA ranges, and multiple devices in the case of an array.  Thus I was looking at creating an OS level API for this type of operation.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">My initial thought was to create two new fields in the bio struct.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">u64 bi_atomic_transaction_id;<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">u32 bi_atomic_transaction_length;<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">A writer would populate multiple bio requests with the same transaction_id and a single write length which is the length of all bio requests.  The bio requests do not need to be linear or adjacent.  There would probably need to be alignment rules.  There would be no requirement that all of the requests are submitted at the same time.  There would probably need to be size and concurrency limits to keep the engine reasonable.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">My concern with just "making up an experimental API" is that, to be useful, it needs to play nice inside of the block layer with other pieces.  For example, if I have a device that supports this API, I would like to be able to use LVM on top of it, or have it as a member of a software mirror set.  This implies that the block stack has a convention to handle layered devices with these transactions embedded within them.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Again, thank you for the links.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Doug Dumitru<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 8, 2015 at 8:38 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"><span class="">On 07/07/2015 08:33 PM, Doug Dumitru wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
... is anyone working on such an animal.  I was thinking of a "struct<br>
bio" extension.  I know that Fusion had a private API for this, but I am<br>
not a Fusion customer so I have not seen their concepts.<br>
</blockquote>
<br></span>
The following document may be helpful: "SBC-4 SPC-5 Atomic writes and reads" (<a href="http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-064r9.pdf" rel="noreferrer" target="_blank">http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-064r9.pdf</a>). Please note that the information about atomic writes in that document has been superseded by the section in the SBC-4 document about atomic writes (<a href="http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc4r07c.pdf" rel="noreferrer" target="_blank">http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc4r07c.pdf</a>).<span class="HOEnZb"><font color="#888888"><br>
<br>
Bart.<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Doug Dumitru<br>EasyCo LLC<br></div>
</div>