On Mon, 2015-04-20 at 07:58 +0200, Hannes Reinecke wrote: > On 04/19/2015 12:56 AM, Christophe Varoqui wrote: > > About five years ago, we faced a somewhat simular issue with > > Symmetrix arrays, where the replicated LU of a SRDF pair (R2) was > > flagged read-only by the kernel upon discovery. Splitting the pair > > with a symcli command made the LU read-write from the array > > controller point of view, but the Linux kernel would not promote it > > read-write dynamically. > > > > I don't know if the Symmetrix array also use a unit attention to > > signal the change to the initiators. If it does, it might be worth > > trying to address both the 3par peer persistance and the Symmetrix > > SRDF situations. > > > > On the other hand, if the SRDF R2 rw promotion issue has been fixed > > since, the patch might give guidance about where/how to plug the > > 3par peer persistance ghost path rescans. > > > It's not only that; if you are faced with LUNs in standby even the > kernel wouldn't detect them properly. > > I'm currently debugging this issue and will have an update soon(-ish). I have a patch set to have the kernel automatically rescan the device when the ALUA state changes to an ACTIVE state, if it couldn't read capacity when the device was initially probed. I've had it for a while, but I haven't had *any* response from the vendor if it actually works with their product, so I haven't posted it to the list for review yet. I did point out to them that the T10 spec does not *prohibit* supporting the READ CAPACITY command in the ALUA standby state, which would avoid the problem, and is what other vendors seem to do. However, they then raised the issue that if the capacity changes in the standby state then they should be generating the capacity changed UA, etc and you can sort of see their point of why this gets complicated. -Ewan > > Cheers, > > Hannes > -- > Dr. Hannes Reinecke zSeries & Storage > hare@xxxxxxx +49 911 74053 688 > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg > GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton > HRB 21284 (AG Nürnberg) > > -- > dm-devel mailing list > dm-devel@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/dm-devel -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
