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

Knight, Frederick Frederick.Knight at netapp.com
Fri May 30 12:07:49 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
I'm not sure I understand how this will work in a MI system.
Host 1:
send TUR - device is not ready
send START - device increments reference count
Host 2:
send TUR - device is ready
send READ/WRITE
Host 3:
send TUR - device is ready
send READ/WRITE
Host 1 finishes its work and:
send STOP - reference count decrements to zero
Host 2/3 now get NOT READY errors.
Do you want to track start/stop state per I_T_L and rather than
globally?  Should host 2 and 3 above get a NOT READY error on their
first access (like host 1), and be forced to send their own start
command?  Then, the STOP command only does a real stop after it receives
a STOP from everyone that sent a START?
That would be totally different than current behavior, and I assume
would require some MODE SENSE/MODE SELECT method to enable/disable.
I look forward to your proposal to see how you pull this all together.
	Fred Knight
-----Original Message-----
From: Rao, Santosh Ananth [mailto:santosh.rao at hp.com] 
Sent: Friday, May 30, 2008 12:36 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:
* "Rao, Santosh Ananth" <santosh.rao at hp.com>
*
I don't believe its an either-or approach. A Mode Page based idle time
can be used to allow the device server to spin-down drives tied to idle
luns. Additionally, host co-operative START/STOP based mechanism can
also be deployed. Those hosts that do not use START/STOP do not benefit
|from the START/STOP method. As with any new feature, it needs changes in
the implementations to take advantage of it.
The idle time based spin-down approach may suffice by itself but can be
expensive in IO completion time when coming out of an idle state and
having to spin up. Certain apps require fail fast behaviour and may not
be able to tolerate the spin-up delay following an idle period. Explicit
indication from the host when the lun is no longer referenced allows for
a graceful and more expedient spin-down rather than wait long periods
based on idle times when the lun may have been closed quite a while ago.
The Power Condition Mode Page timers need not be mutually exclusive with
the START/STOP usage. As Paul suggested, the timers do not need to be
disabled with START/STOP UNIT. However, rather than spin down on the
first STOP UNIT, being multi-initiator aware by tracking START/STOP per
I-T-L and spinning down on the last STOP would make this more MI aware
while taking advantage of host notifications when the lun is no longer
actively referenced by the host.
As currently defined, the STOP UNIT is un-usable by hosts in MI
environments due to the command specification being MI un-aware. No
guidance is provided by SBC-3 on MI implications to STOP UNIT. It would
be good for the START/STOP UNIT cmd specification to be enhanced to
cover the MI aspects such that spin-down on the device server side only
occurs on the last STOP UNIT based on I-T-L state tracking.
Thanks,
Santosh Rao
HP-UX Storage.
> -----Original Message-----
> From: Knight, Frederick [mailto:Frederick.Knight at netapp.com]
> Sent: Friday, May 30, 2008 8:31 AM
> To: Rao, Santosh Ananth; Paul Suhler; t10 at t10.org
> Subject: RE: Drive behavior issue when START STOP unit forces drive to
> idle power condition
>
> 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
*
* 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