On Mon, 2022-04-11 at 20:59 -0500, Benjamin Marzinski wrote: > Some storage arrays can be accessed using multiple protocols at the > same > time. I've have customers request the ability to set different > values > for the path specific timeouts, like fast_io_fail_tmo, based on the > protocol used to access the path. In order to make this possible, > this > patchset adds a new protocol subsection to the device subsection and > the > overrides section. This allows users to set a device config's path > specific timeouts, such as dev_loss_tmo, fast_io_fail_tmo, and > eh_deadline on a per-protocol basis. Sigh... I am not happy about this amount of additional complexity in the multipath configuration. It is already so complicated that hardly anyone really understands how it works. I fully agree that some properties, in particular fast_io_fail_tmo [1], are rather properties of protocol or fabrics than a storage array. But do we really need to differentiate by both "device" and "protocol"? IOW, do users need different fast_io_fail_tmo value for the same protocol, but different arrays? My feeling is that making this property depend on a 2-D matrix of (protocol x storage) is overcomplicating matters. And _if_ this is necessary, what do we gain by adding an "overrides" on top? [2] What about adding simply adding "protocols" as a new top section in the conf file, and have the per-protocol settings override built-in hwtable settings for any array, but not explicit storage-device settings in the conf file? Regards, Martin [1]: wrt dev_loss_tmo, I tend to think that the best value must be found based on neither protocol nor array, but data center staff. [2]: I strongly dislike "overrides", in general. I wonder what we need it for, except for quick experiments where people are too lazy to add explicit settings for devices and/or multipaths. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
