> On Jan 27, 2023, at 12:43 PM, Bart Van Assche <bvanassche@xxxxxxx> wrote: > > On 1/27/23 11:57, Brian Bunker wrote: >> So the question becomes how should initial scan work when a LUN has a PQ=1 set. >> It is a valid, by spec with ALUA state unavailable but doesn’t seem to be >> handled. Why allow an sg device but not an sd one on initial scan in this case? There >> are probably many ways to fix this. I think the simplest is to allow sd device creation >> on LUNs were PQ=1, and only restrict PQ=3. I am not sure the side effect of this on other >> targets. The other approach which will no longer work after the revert is to trigger a >> rescan from the target. This is sub-optimal since it is disruptive. Any approach involving >> the ALUA device handler will not help since there is no device to transition if it is >> discovered with PQ=1. > > When Mike Christie and I looked into the ALUA unavailable state many years ago we concluded that using this state is so troublesome that it's better not to use this state. How about using active/optimized and active/non-optimized instead? I can’t do that because active/non-optimized is just advisory. If a request comes down that path it must succeed. In our case, we can’t allow that. Our only choice is between non-active ALUA states. We can use standby but that invites SCSI commands we would rather not have to deal with, most notably persistent reservations. ALUA unavailable is the attractive one but it comes with the PQ=1 baggage. Thanks, Brian > Thanks, > > Bart. >
