SES-2 : Peer enclosure services processes with common managed elements

Elliott, Robert (Server Storage) Elliott at
Wed Jan 25 11:27:35 PST 2006

* From the T10 Reflector (t10 at, posted by:
* "Elliott, Robert (Server Storage)" <Elliott at>

> -----Original Message-----
> From: owner-t10 at [mailto:owner-t10 at] On Behalf 
> Of Fore, Chris
> Sent: Wednesday, January 25, 2006 9:05 AM
> To: t10 at
> Subject: SES-2 : Peer enclosure services processes with 
> common managed elements 
> We have some questions regarding the application of SES-2 to 
> peer Enclosure Services (ES) processes. 
> For this discussion, we refer to Figure 2 from T10 document 
> 03-347r1 ("SES-2 Reporting peer enclosure service 
> processes").  This figure is accompanied by the following 
> explanatory text (excepted here for reference convenience): 
>    "Figure 2 shows multiple enclosure service processes. Both 
>    return the same enclosure serial number, etc. in the 
>    Configuration diagnostic page. They might each have the ability 
>    to manage the full enclosure or just part of it (this can be 
>    determined by examing which elements they manage)."
> The peer ES processes shown in figure 2 might have the 
> following relationships with respect to managed elements: 
> A) Both ES processes manage the same elements. 
> B) Each ES process manages a disjoint set of elements (no 
> elements in common). 
> C) The ES processes manage overlapping sets of elements (some 
> common elements, some unique). 
> QUESTION ONE: Are all three of these relationships permitted 
> by the standard? 

Yes, but A) and C) will each have difficulties with some of
the element types.

For example, if they share a Cooling element, and one requests
a fan speed of 111b and the other requests 001b, what speed
should the fan run at?

The Enclosure Services Controller Electronics element's SELECT
ELEMENT bit can be used to select an enclosure services process
as the "active" one.  This might be used to choose one of
the processes as the owner of any shared elements, letting the
other control them only if the active one fails - either
detected by the enclosure services processes themselves or
selected by software setting the SELECT ELEMENT bit to one
in the non-active one.

If one is not favored over the other, then perhaps the last
one to update an element gets what it requests.  Some
bits might make sense ORed or ANDed together.  This approach
seems unpredictable.

> QUESTION TWO: Assuming for the moment that case (C) above is 
> permitted, then which of the following implementation 
> alternatives are consistent with the standard? 
> ALTERNATIVE ONE: Each ES process reports multiple 
> subenclosures, with the common elements in the primary 
> subenclosure and the unique elements in distinct subenclosures.
> ALTERNATIVE TWO: Each ES process reports a single 
> subenclosure which contains all the elements that it manages.

I think of subenclosures more as complete enclosures that just
happen to be accessed via a primary subenclosure, rather than
as parts of the same enclosure.  This leads to alternative two.

Alternative 1 is subject to delivering a unique NAA identifier for 
each subenclosure in the Configuration diagnostic page ENCLOSURE
LOGICAL IDENTIFIER field, which seems unlikely.

> Thanks in advance, 
> :: R. Chris Fore
> :: Adaptec, Research Triangle Park, NC 
Rob Elliott, elliott at
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

More information about the T10 mailing list