Mr. Assche,
Thank you for the T10 links. I was actually looking for something at a different level.
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.
My initial thought was to create two new fields in the bio struct.
u64 bi_atomic_transaction_id;
u32 bi_atomic_transaction_length;
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.
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.
Again, thank you for the links.
Doug Dumitru
On Wed, Jul 8, 2015 at 8:38 AM, Bart Van Assche <bart.vanassche@xxxxxxxxxxx> wrote:
On 07/07/2015 08:33 PM, Doug Dumitru wrote:
... is anyone working on such an animal. I was thinking of a "struct
bio" extension. I know that Fusion had a private API for this, but I am
not a Fusion customer so I have not seen their concepts.
The following document may be helpful: "SBC-4 SPC-5 Atomic writes and reads" (http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-064r9.pdf). 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 (http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc4r07c.pdf).
Bart.
--
Doug Dumitru
EasyCo LLC
EasyCo LLC
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
