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

[Matthew Wilcox <matthew@wil.cx>]

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.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."