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

Knight, Frederick Frederick.Knight at netapp.com
Fri May 30 08:31:10 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
I'm not convinced this can work at all.  Many hosts don't issue START.
They begin their operation with a TUR, and if it's ready, they just use
it.  So the target never sees a START at all.  If the target can't
depend on the START, what can it depend on to increment the reference
count - any I/O?  That defets the purpose, since the device could never
really tell when it is being used and when it is not.
I think tracking START/STOP reference counts per I_T_L is dangerous.
The whole point of these timers is that the target knows what is going
on.  It knows when it is being accessed, and when it is not being
accessed.  When the access pattern (at the device) becomes reduced, then
the device (target, lun, whatever) can begin to save power.  With
multiple initiators all accessing the same device, the device is the
only place this can be coordinated.  To tie this to just the START/STOP
sequences reduces the ability of the device to really save power when
access patterns would otherwise allow it to reduce power.
	Fred Knight 
-----Original Message-----
From: Rao, Santosh Ananth [mailto:santosh.rao at hp.com] 
Sent: Thursday, May 29, 2008 8:25 PM
To: Paul Suhler; 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>
*
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
*
* 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