SES-2 use of SWAP bit for multiple clients

Elliott, Robert (Server Storage) Elliott at hp.com
Fri Feb 15 16:21:08 PST 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf
> Of Morrie Gasser
> Sent: Tuesday, February 12, 2008 11:38 AM
> To: t10 at t10.org
> Subject: SES-2 use of SWAP bit for multiple clients
>
> * 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.
SES was begun in parallel SCSI days before multiple initiators were
common, so probably doesn't handle everything well.  Worst case, you
might need to treat it like a disk in a cluster and use persistent
reservations to coordinate access.
> 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.
That follows standard SCSI conventions for unit attention conditions.
> Also the INVOP bit is maintained on an I_T nexus basis.
Standalone enclosure services processes do so; attached ones do not
(since the Fibre Channel disk drive doesn't pass along the initiator
identity over the ESI interface).
>
> 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.
SES-2 is in letter ballot comment resolution right now.  We could take
a late comment to have standalone enclosure services processes handle
SWAP/RST SWAP like INVOP and maintain the state on a per-I_T nexus basis.
Attached enclosure services processes are stuck with the current
definition, though.  Let me know if you'd like to submit that as
a comment.
--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
*
* 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