On 02/21/16 22:59, Hannes Reinecke wrote:
The main reason why I need the 'access_state' attribute is to decouple
the multipath daemon; at the moment the multipath daemon has to issue
REPORT TARGET PORT GROUPS frequently to figure out the status, which is
causing quite some load on the target. When using the 'access_state'
attribute we would avoid doing I/O for that and have a consistent view,
both on the kernel and the multipath daemon side.
But it's actually a good thing to have the 'access_state' patch in a
different series; I've got some more patches converting the remaining
device_handler to also supply the 'access_state' values.
Hello Hannes,
The above sounds very interesting to me. Will multipathd recognize at
run-time whether or not the kernel supports the sysfs ALUA state
attribute ? Will ALUA state changes be reported through udev or will
multipathd poll the sysfs ALUA state attributes ? And if the netlink
buffer that is used in multipathd to receive udev events overflows
(ENOBUFS), will multipathd resynchronize its state ? As far as I can see
in source file libmultipath/uevent.c today multipathd ignores netlink
buffer overflows.
Thanks,
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
