[gop at us.ibm.com]

* From the T10 Reflector (t10 at t10.org), posted by:
* gop at us.ibm.com
*
As Jeff Williams pointed out to me when we were working on packetized and I
wanted to lift the 'data only in one direction' rule; the problem has
nothing to do with the target, it's the initiators. The problem is that
SCSI only defines one set of pointers for each nexus. To move data in both
directions SCSI (and more important initiators) will have to have two more
pointers for data. I would assume that in addition to the current data
pointer we would have to add in a data in pointer and a data out pointer.

Bye for now,
George Penokie

Dept Z9V  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880



hafner at almaden.ibm.com on 07/17/2000 06:13:56 PM

To:   t10 at t10.org
cc:   Dave_Anderson at notes.seagate.com
Subject:




* From the T10 Reflector (t10 at t10.org), posted by:
* hafner at almaden.ibm.com
*


Folks,
There was an interesting discussion at the last T10 meeting on OSDs
(osd-r01).  I presented some suggestions in 00-262r0, and a reply
(00-295r0) was supplied by Dave Anderson (Seagate).  In many cases, we
agreed on many things.   A few things I raised questions about because I
wasn't clear on the issues and requirements.  A few things we disagree on
mostly in terms of implementation. But....

One issue that I want to open for discussion here is the CREATE.  I didn't
see how a CREATE could include write data (DataOut) and still get back an
ObjectID in DataIn, so I suggested separating the two operations.
Dave remarked that "this seemed wasteful in an environment where there are
a lot of small file creates" (from 00-295r0, last page, item 6).

My response is:
1) if or until there is bidirectional data on a single SCSI command, I
don't see an immediate and good alternative but...

2) one could CREATE+WRITE with no returned ObjectID, and then follow that
with a second command to request a report on the created object's ID
(that's still two commands though there is better atomicity of
CREATE+WRITE)

3) one could CREATE+WRITEw/suggested ObjectID and then the OSD can return
Status GOOD if the ObjectID was acceptable (to the OSD) and some other
status (CHECK CONDITION and include in the additional sense data the actual
ObjectID that was assigned by the OSD). This is a hack (in my opinion) but
workable, though it does distribute "namespace" responsibilities in a
different way.

4) The filesystem that expects to open lots of small files could issue a
number of CREATE commands and cache the ObjectIDs for when a real file
needs to be created.  This modifies the filesystem behavior, but is not
unreasonable.

5) We can mitigate the latency and overhead of many CREATES (as in (4)) by
having a CREATE MULTIPLE (create 'n' objects) which would return a list of
ObjectIDs.  Interesting error scenarios arise in this case, however.

Anybody else got thoughts on this?

Anybody want to bite off changing SAM to allow for bi-directional data?

Jim Hafner


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



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