SAM requirements for ACA on unsupported logical unit?

[Stephen Byan]

* From the T10 Reflector (t10 at t10.org), posted by:
* Stephen Byan <Stephen.Byan at quantum.com>
*
My problem with creating an ACA is that it requires per-logical-unit state.
This state consist of 

1) a boolean indicating the ACA condition exists,
2) a boolean indicating whether this is a Normal ACA or not.
3) an (up to 64 bit) integer identifying the faulting initiator.

So creating an ACA for an unsupported logical unit would mean that a target
would have to potentially maintain this state for all addressable logical
units. In fibre channel land this can be a large number. (In SAM-land this
is even a 64-bit number!) In the worst-case scenario, there could be an
active ACA for every addressable logical unit. It seems unreasonable to me
to specify that a target should maintain this much state for unsupported
logical units.

If a target dynamically-allocates the memory for this state, what should it
do when this resource is exhausted? Return BUSY status to commands directed
at unsupported logical units?

My preference would be to either special-case this condition and a) disallow
the establishing of an ACA or b) allow a target to map all unsupported
logical units to one, thus allowing only one ACA condition to exist at a
time amoung the set of unsupported logical units. Option b) implies that
once an ACA is established for one unsupported logical units, commands
directed to other unsupported logical units would be rejected with ACA
ACTIVE status.

On second thought, maybe returning BUSY on resource exhaustion isn't such a
bad idea...

Regards,
-Steve Byan


-----Original Message-----
From: Gerry_Houlder at notes.seagate.com
[mailto:Gerry_Houlder at notes.seagate.com]
Sent: Monday, November 15, 1999 6:03 PM
To: t10 at t10.org
Subject: Re: SAM requirements for ACA on unsupported logical unit?


* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry_Houlder at notes.seagate.com
*
The only thing you have "missed" is that the standard doesn't allow any
exception for commands directed to unsupported LUNs. My reading of the
standard
paragraphs you quote require the setting of an ACA (not a CA like you
describe)
when NACA=1. I think the target should act like the standard says. If
initiators
don't like this behavior, they can simply use NACA=0 until they are sure the
target actually supports the LUN in question. Or we can change the standard.

Feel free to propose wording changes to describe you desired behavior.


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org