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
