Object oriented issues

[Richard Golding]

* From the T10 Reflector (t10 at t10.org), posted by:
* Richard Golding <golding at panasas.com>
*
I wanted to follow up on what Dave Anderson said about data transfers in
two directions: 

> This issue of data transfers in both directions
> is a tough problem for SCSI, but at the same time, I think required for
> efficiently implementing OBSD.  [...] 
> Also, Jim's suggestions for alternative solutions to the
> problem are worthwhile, though I actually think that more instances will
> arise for employing bi-directional transfers.  If that is the case, then it
> is better we come to this realization earlier than later.  Still, I would
> really prefer to find a way to make it work in SCSI, if at all possible.

The OSD work is pushing SCSI into an environment it has not much dealt
with so far -- that of really network-attached storage, where multiple
systems will concurrently share data on storage devices.  In distributed
environments like this, it is important to very carefully delimit the
atomicity of operations, and often it's important to request a change to
something and, atomically, ensure that it has had the desired effect. 
Or at the very least, it's often important to be able to (for example)
set security information when creating an object.  And that's just for
correctness; performance can also be a pretty compelling for
bidirectional transfer for a single command.

As Dave pointed out, this isn't a practical problem: Seagate has built
drives that do this; and iSCSI (and it sound like FCP) can handle
bidirectional data transfers without a problem -- since iSCSI, at least,
is built on top of a network transport that already handles this sort of
thing.  I personally expect OSDs to be important in networked
environments that use transports like FCP and iSCSI; I don't expect to
have one in my desktop.  (I don't even have a parallel SCSI drive in my
desktop, because Linux on PC hardware doesn't need SCSI features in such
a simple, locally-attached environment.)  Perhaps the solution would be
to make the OSD protocol reliant on support for bidirectional transfer
in the transport, and make support for bidirectional transport
optional.  This makes for two distinct classes of transport and raises
all sorts of issues with the idea that the standards provide a certain
level of transparency, but in practice the distinction already exists
between local attachment and shared networks.

-richard
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org