00-140r0 - Bug in SAM-2 Task Identifier Definition
ralphoweber at CompuServe.COM
Sun Mar 5 05:36:08 PST 2000
* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <ralphoweber at compuserve.com>
} The Task Identifier is consumed at the Device Server,
} which is an LU entity, not a target entity. An LU may
} be attached to an initiator via one or more targets/ports.
} The Target ID is intended to identify that entity.
The description of the problem is correct. However, its
use as a justification for the definition of the Task
Identifier object is on very thin ice with respect to
SAM (ANSI X3.270:1996). SAM does not describe a model
for multi-port devices.
In SAM-2, the problem described above is addressed by
the addition of a Port Identifier object (see 4.9.2
and 4.9.3 on PDF page 49 in sam2r12.pdf, and 4.10.2
on PDF page 51).
The SAM-2 model for multi-port devices is still under
development. However, I believe that having a separately
named Port Identifier object will survive the development
The Port Identifier need not be identical to the Target
Identifier, which allows implementations that use other
identifiers such as PCI bus address to distinguish ports.
Furthermore, a dual ported target could be configured
on to separate SCSI Busses and be given the same
Target Identifier on each port/bus. Therefore, Target
Identifier is not guaranteed to be a unique identifier
for the port.
} Two tasks delivered by the same initiator to the same
} LU but through different target/ports are considered
} to be separate and distinct.
This statement is true. However, it leaves the incorrect
impression that the target might somehow be able to
recognized that the two tasks are from the "same
initiator." The SCSI model for multi-port devices
provides no way for a target to know that the same
initiator is sending tasks via two different ports.
I doubt that future developments in the model will
} You did not describe the FCP-2 problem clearly.
} Please be more explicit?
See FCP-2 Letter Ballot Results (T10/00-005r0) ENDL
comment 40 (PDF page 13).
} Note, you can not directly address the "target/port"
} at the SCSI ULP.
If this statement is meant to apply to application
clients, then it is both true and false. The SAM-2
model under development prohibits sending a command
to one target port and requiring that the data be
transferred on a different target port, as such
no naming mechanism is provided for identifying
the different target port. On the other hand,
the application client addresses a SCSI command
to a specific Target Identifier, which must of
necessity address a specific target/port.
} All task management commands are ultimately
} delivered to an LU's device server.
This statement conflicts with SAM and SAM-2.
Task management functions are addressed to the
Task Manager, which is an object within the
Target. See SAM-2 4.7.4 (PDF page 46) or SAM
4.7.3 (PDF page 34 in sam-r18.pdf), the wording
is identical in both:
"The task manager controls the execution of one
or more tasks by servicing the task management
functions specified in clause 6."
} Some are broadcast to more than one.
There is no broadcast function in SCSI.
} The port level LLP through task manager to ULP
} device server mapping has always been LLP specific.
} Addressing the target/port is an LLP operation.
This represents a positioning of the Task Manager
that I had not considered. I always envisioned
the Task Manager at the same layer as the Device
Server, probably because the Application Client
(clearly just one layer) addresses requests
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10