gop at gop at
Tue Jul 18 08:37:04 PDT 2000

* From the T10 Reflector (t10 at, posted by:
* gop at
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
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880

hafner at on 07/17/2000 06:13:56 PM

To:   t10 at
cc:   Dave_Anderson at

* From the T10 Reflector (t10 at, posted by:
* hafner at

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

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

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

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

More information about the T10 mailing list