Re: [PATCH 1/1] : Spinning up disk is observed on standby paths until timeout, resulting in longer path restoration time.

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Fri, 2009-02-20 at 08:52 -0700, Matthew Wilcox wrote:
> On Fri, Feb 20, 2009 at 03:36:22PM +0000, James Bottomley wrote:
> > > +                   sshdr.asc == 4 && (sshdr.ascq == 3 || sshdr.ascq == 0x0b ||
> > > sshdr.ascq == 0x0c) ) {
> > > +                       break;  /* manual intervention required || Standby ||
> > 
> > This really doesn't look right ASC/ASCQ 0x04/0x0b is LUN not accessible;
> > target *port* in standby state. That's supposed to be because it was put
> > into a standby state according to SPC3(r23) 5.8.2.4.4
> > 
> > I don't see how a port (target) is expected to come out of standby with
> > a LUN command.  The standard implies you need to do it with a set target
> > port groups command.  What array is actually giving this?
> 
> The port isn't coming out of standby state.  We send it a TEST_UNIT_READY,
> it replies with a 0x04/0x0b.  At that point, we currently decide to send
> it a START_STOP and wait 100 seconds.  This is clearly a crappy decision
> on our part, we should just bail.

So we should be bailing on manual intervention, TP standby and TP
unavailable?  It looks like TP assymetric access transition is waitable.

It also looks like offline and notify (enable spinup) required are also
not worth waiting for ... although the latter is a SAS power management
state which it's not clear to me how to handle properly.

James