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

Rao, Santosh Ananth santosh.rao at hp.com
Fri May 30 09:36:10 PDT 2008


* 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



More information about the T10 mailing list