On 06/09/2016 04:20 PM, Xose Vazquez Perez wrote:
> On 04/29/2016 07:55 AM, Hannes Reinecke wrote:
>
>> On 04/29/2016 12:06 AM, Sebastian Herbszt wrote:
>>>
>>>> diff --git a/libmultipath/hwtable.c b/libmultipath/hwtable.c
>>>> index a4ae053..28ee595 100644
>>>> --- a/libmultipath/hwtable.c
>>>> +++ b/libmultipath/hwtable.c
>>>> @@ -175,6 +175,21 @@ static struct hwentry default_hw[] = {
>>>> .prio_name = PRIO_ALUA,
>>>> .prio_args = NULL,
>>>> },
>>>> + {
>>>> + /* HP MSA 1040/2040 product family */
>>>> + .vendor = "HP",
>>>> + .product = "MSA (1|2)040 SA(N|S)",
>>>> + .features = DEFAULT_FEATURES,
>>>> + .hwhandler = DEFAULT_HWHANDLER,
>>>> + .pgpolicy = GROUP_BY_PRIO,
>>>> + .pgfailback = -FAILBACK_IMMEDIATE,
>>>> + .rr_weight = RR_WEIGHT_NONE,
>>>> + .no_path_retry = 18,
>>>> + .minio = 100,
>>>> + .checker_name = TUR,
>>>> + .prio_name = PRIO_ALUA,
>>>> + .prio_args = NULL,
>>>> + },
>>>>
>>>> {
>>>> /* HP SVSP */
>>>
>>> Any reason for a separate entry and not merging it with
>>> "HP MSA2000 product family with new firmware" ?
>>>
>> Yes. MSA2000 are completely different beasts, so I'd like to keep
>> them separate.
>
> Sebastian is right.
>
> And these three can be folded into one, because they share *exactly* the
> same configuration.
>
Note that I didn't say they _cannot_ be merged.
I've said that I would _like_ to keep them separate, being as they are
totally different hardware-wise.
> /* HP MSA2000 product family with new firmware */
> .vendor = "HP",
> .product = "MSA2012sa|MSA23(12|24)(fc|i|sa)|MSA2000s VOLUME",
>
> /* HP P2000 family arrays */
> .vendor = "HP",
> .product = "P2000 G3 FC|P2000G3 FC/iSCSI|P2000 G3 SAS|P2000 G3 iSCSI",
>
> /* HP MSA 1040/2040 product family */
> .vendor = "HP",
> .product = "MSA (1|2)040 SA(N|S)",
>
>
> In VxVM(libvxmsa2kfc_sa) they are grouped that way:
> https://web.archive.org/web/20160608233140/https://sort.veritas.com/asl/details/756
>
> Otherwise if hwtable.c is filled with a lot of duplicate entries,
> it could be unmanageable.
>
Well.
MSA2000 is already out of support, and P2000 is heading there.
So it's _extremely_ unlikely that we get additional hardware entries for
those.
At the same time, re-grouping hardware entries by combining regular
expressions always has the real risk of messing up the regular
expressions, and requires a test on the actual hardware to check if we
didn't mess up. Seeing the both are basically unsupported it'll get hard
to validate this.
For this reasons I prefer to leave them alone.
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
