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

Rao, Santosh Ananth santosh.rao at hp.com
Fri May 30 12:31:50 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* "Rao, Santosh Ananth" <santosh.rao at hp.com>
*
Currently, STOP UNIT is un-usable in MI environments due to lack of any
guidance in the spec about how it should be handled with MI. In the absence
of any guidance, the assumption is the first STOP UNIT shall cause spin-down,
regard-less of the presence of other initiators. As a result, STOP UNIT is
not used by hosts for a spin-down when needed.
Should we move forward with a host-storage co-operative power management
proposal that allows for hosts to indicate to the storage when a particular
lun is no longer being referenced, the MI aware co-operative host/storage
power mgmt would need to be explicitly enabled (either a mode page bit or a
bit in the START UNIT when first issued).  STOP UNIT would need to be issued
on close of the lun on each I-T-L by the host. This use of START/STOP UNIT by
the host requires a common model for the given lun across initiators
accessing that lun.
In the case you describe below, the host initiators would need to be enhanced
to perform the explicit power management and all initiators would need to be
capable of the START/STOP protocol. You're right in that it would be enabled
explicitly via a mode page bit or a bit in the START UNIT which is enabled
assuming other hosts are performing the same START/STOP protocol.
Thanks,
Santosh
> -----Original Message-----
> From: Knight, Frederick [mailto:Frederick.Knight at netapp.com]
> Sent: Friday, May 30, 2008 12:08 PM
> To: Rao, Santosh Ananth; t10 at t10.org
> Subject: RE: Drive behavior issue when START STOP unit forces
> drive to idle power condition
>
> 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