Drive behavior issue when START STOP unit forces drive to idle power condition

Rao, Santosh Ananth santosh.rao at hp.com
Thu May 29 17:25:08 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* "Rao, Santosh Ananth" <santosh.rao at hp.com>
*
Assuming the device server is maintaining state per I-T-L nexus, a second
START UNIT received on the same I-T-L nexus when the prior START UNIT has not
been STOP UNITed shall not result in an increment of the reference count on
that I-T-L.
Host application clients perform the scsi cdb activity on their first
reference (open) and last de-reference (close). Should the host or an
individual lun or individual I-T-L crash without a graceful de-reference
(close), the device server would see a duplicate START UNIT without a prior
STOP UNIT causing it to discard as a duplicate.
There would be additional areas to explore such as recovery from lost I-T
nexi (in case of login based transports), recovery from target device or
individual LU or I-T-L reset or power cycle (dealing with hosts which do not
re-open the I-T-L and re-issue START UNIT on 06/29/00).
It will need some work to get this right but is worth the effort to look at
host-device co-operative power management of the storage for both JBOD drives
as well as smart power handling of the back-end drives mapped to logical
units. Would also be good to have a Mode Page capability to specify spin down
of the drive based on a configurable idle time and implicit spin-up on the
next IO issued to that drive. This can then be extended to raid controller
logical units exposed to the host app clients and map the idle spin-down time
of the LU to back-end drives.
Thanks,
Santosh Rao
HP-UX Storage.
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf
> Of Paul Suhler
> Sent: Thursday, May 29, 2008 4:51 PM
> To: t10 at t10.org
> Subject: RE: Drive behavior issue when START STOP unit forces
> drive to idle power condition
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Paul Suhler" <Paul.Suhler at Quantum.Com>
> *
> There's a potential issue with this, which the media changer
> community ran into with the PREVENT/ALLOW MEDIUM REMOVAL
> command.  If one of the initiators issues a START UNIT and
> then dies, the count will never get back to zero.  After the
> initiator recovers, it's unlikely that it will remember that
> it has an outstanding START and needs to issue a STOP.
>
> Cheers,
>
> Paul
> ___________________________________
> Paul A. Suhler | Firmware Engineer | Quantum Corporation | Office:
> 949.856.7748 | paul.suhler at quantum.com
> ___________________________________
> Disregard the Quantum Corporation confidentiality notice
> below.  The information contained in this transmission is not
> confidential.
> Permission is hereby explicitly granted to disclose, copy,
> and further distribute to any individual(s) or
> organization(s), without restriction.
>
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf
> Of Rao, Santosh Ananth
> Sent: Thursday, May 29, 2008 3:59 PM
> To: Gerry.Houlder at seagate.com; t10 at t10.org
> Subject: RE: Drive behavior issue when START STOP unit forces
> drive to idle power condition
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Rao, Santosh Ananth" <santosh.rao at hp.com>
> *
> It would be worth exploring alternatives for the target
> device (either individual JBOD drives or array controllers)
> to track the number of START UNITs received from individual
> I-T-L nexi (or hosts per logical
> unit) and count down the corresponding STOP UNITs so that the
> drives corresponding to the logical unit can be spun down
> when the STOP UNIT count matches the START UNITs initially received.
>
> Being able to track host closure of all active references to
> a logical unit allows the target device to conserve power by
> spinning down the drive or set of drives mapping to that
> logical unit when the last application reference to the
> logical unit has been closed (volume group de-activated on
> the host, filesystem unmounted, database shutdown, etc).
>
> Thanks,
> Santosh Rao
> HP-UX Storage.
>
>
>
> > -----Original Message-----
> > From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
> > Gerry.Houlder at seagate.com
> > Sent: Thursday, May 29, 2008 1:55 PM
> > To: t10 at t10.org
> > Subject: Drive behavior issue when START STOP unit forces drive to
> > idle power condition
> >
> > * From the T10 Reflector (t10 at t10.org), posted by:
> > * Gerry.Houlder at seagate.com
> > *
> >
> > While working on my additional idle power conditions proposal
> > (08-184) I encountered this issue with using START STOP
> UNIT command
> > to force the drive to idle mode.
> >
> > Situation: initiator sends START STOP UNIT command that
> forces drive
> > to idle power condition. As defined today, this action disables any
> > timers on the Power Condition Mode page (page 0x1A) that
> happen to be
> > enabled. Later a media access command causes the drive to
> transition
> > to active state to process the command. Since the timers
> are disabled,
>
> > the drive will stay in active state until another START STOP UNIT
> > command is sent.
> >
> > Problem: With multi-initiator systems, will all the
> initiators know to
>
> > send a START STOP UNIT command to put the drive back to idle to
> > conserve power?
> > If not, a drive that at least one initiator thinks is in an
> idle power
>
> > condition (conserving power) may actually be in active
> power condition
>
> > for long periods of time.
> >
> > Possible solution: change the START STOP UNIT command
> behavior so that
>
> > sending the command causes the drive to transition
> immediately to the
> > requested power condition but don't disable the timers. Then if the
> > drive goes to active power condition to process a media access
> > command, it will still go to idle  power condition based on the
> > timers. This would at least limit the unnecessary active
> time of the
> > drive to the values set in the timers.
> >
> > I'd like to hear what other companies think of this situation. Will
> > drives always be fully manged in a multi-initiator system so the
> > stated problem will not be an issue or should something be
> changed to
> > limit the impact of this issue? Are there existing implementations
> > that use the current START STOP UNIT behavior? If not,
> perhaps we can
> > consider changing the behavior.
> >
>
> -----------------------------------------------------------
> The information contained in this transmission may be
> confidential. Any disclosure, copying, or further
> distribution of confidential information is not permitted
> unless such privilege is explicitly granted in writing by
> Quantum Corporation. Furthermore, Quantum Corporation is not
> responsible for the proper and complete transmission of the
> substance of this communication or for any delay in its receipt.
> ------------------------------------------------------------
> *
> * 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



More information about the T10 mailing list