Re: The PQ=1 saga

["Martin K. Petersen" <martin.petersen@oracle.com>]

Brian,

> For a completely separate reason I would like to see PQ=1 expose the
> sd device.

The host RAID controller case we could probably cover without relying on
PQ=1 at all (we kind-of already do). But there are also storage arrays
out there that rely on PQ=1 to inhibit devices being claimed.
Historically they did this because some other operating systems couldn't
handle a processor device type. So I suspect that keying off of TPGS
alone is probably not sufficient to determine whether PQ=1 should cause
us to attach a ULD or not in your scenario.

> ALUA state transitions from unavailable back to another state does not
> work depending on what state devices are in when they are initially
> discovered.  In the ALUA unavailable state the peripheral qualifier of
> the device should also be set to 001b.

Yep, an unfortunate wrinkle in the spec (although it makes sense).

> This hole makes the unavailable ALUA state unattractive. Allowing the
> peripheral qualifier set to 001b to still create an sd device on
> discovery corrects this hole.

Does your implementation actually support READ CAPACITY etc. in
unavailable state? Otherwise we'd end up with zero-length, read-only
block devices with no logical block size. And we've been down that path
before and that is no fun.

I suspect it would be better to trigger a re-probe of the device when
transitioning out of unavailable state. Most of the logic is already in
place and we reread VPD pages, etc. I believe there are only a few
pieces missing from being able to do a full in-place update.

-- 
Martin K. Petersen	Oracle Linux Engineering