SES-2 use of SWAP bit for multiple clients

Morrie Gasser mgasser at
Tue Feb 12 09:37:40 PST 2008

* From the T10 Reflector (t10 at, posted by:
* Morrie Gasser <mgasser at>
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 
* 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