SES-2 use of SWAP bit for multiple clients
Morrie Gasser
mgasser at emc.com
Tue Feb 12 09:37:40 PST 2008
* From the T10 Reflector (t10 at t10.org), posted by:
* Morrie Gasser <mgasser at emc.com>
*
I am confused about how SES-2 intended the application client to use
the SWAP bit in the status element (7.2.3) when there are multiple
initiators. It seems that SES goes to some lengths to insure that if
multiple clients are accessing the same enclosure services
application (over separate SCSI initiators), the clients don't mess
each other up (except where unavoidable considering they are managing
the same physical hardware).
For example a change in generation code establishes a unit attention
on every I_T nexus, which the SES process clears only by receiving a
configuration page request on each particular I_T nexus. Also the
INVOP bit is maintained on an I_T nexus basis.
However the SWAP bit, whose purpose is to inform the client that
something changed (not to report a physical state of hardware) is not
maintained on an I_T nexus basis. So if one client acknowledges the
change by setting the RST SWAP bit in the control element before the
other clients have had a chance to see the bit, the other clients
won't know there was a swap. In practice, it's mandatory for a
client to issue RST SWAP bit quickly, before doing anything at all
with the device, such as reading or writing to it, or the client
might miss another swap that occurred between the operation and the
RST SWAP. The need to do this quickly almost guarantees that other
clients will miss it.
So in a multi-client situation, how can clients possibly rely on the
SWAP bit without coordinating with each other? If they have to
coordinate about SWAP, why not make them coordinate about the
generation code changes, too? I'm wondering if there was some model
of client behavior or workaround that the committee had in mind, that
would justify this seeming inconsistency for multi-client environments.
Another possibility is that the standard was never intended to solve
multi-client coordination problems, and that the reason for
establishing a unit attention for the generation code change is
simply to inform the client about the condition sooner than it would
find out if it just relied on checking the generation code or sense
code next time it sent or received a diagnostic page. Once the
decision is made to use unit attention, it has to be per-I_T nexus by
definition. The rationale for maintaining the INVOP bit on a per-I_T
nexus basis is less clear, if multi-client applications weren't being
considered.
*
* 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
mailing list