On 12/11/2017 01:50 PM, Guan Junxiong wrote: > Hi Christophe, Hannes, Martin, Xose and Benjamin, > > It is beneficial for our customers if we integrate a new path group > prioritizer into the multipath-tools. > But this prioritizer is vendor-specific and it only works for Huawei storage > system. Will the community > accept such new vendor specific path group prioritizer in > libmultipath/prioritizers? > > I know that the multipath-tools accepted some vendor specific prioritizer > such as emc.c , hp_sw.c, ontap.c and > so on in the libmultipath/prioritizer in 2008~2010 and there were no newer > vendor specific prioritizer. > Before I get down to writing a new Huawei prioritizer, I want to hear your > thoughts. > > If it is convenient for some of you , please let me know your ideas. Thanks. > The overall idea back then was that every new array would be using ALUA to managing priorities, and that no new vendor-specific prioritizer would be needed.
We know we have a deficiency if an array is connected via two distinct transports (ie on path on FC and on path on iSCSI), as this should affect priorities. But that should rather be handled in a generic level and not in a vendor-specific manner. So why do you think a vendor-specific prioritizer is required? Does the Huawei array not support ALUA? Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking h...@suse.de +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@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
