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.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
