On Tue, 2016-02-23 at 18:27 +0800, Hannes Reinecke wrote: > On 02/22/2016 11:34 PM, Bart Van Assche wrote: > > 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 ? > That was the plan. > (Not that I've got any idea _how_ to do this ATM :-) > > > Will ALUA state changes be reported through udev or will > > multipathd poll the sysfs ALUA state attributes ? > Polling. udev events will be too unreliable here, as each uevent > potentially causes I/O during uevent processing which might stall as the > path might be down. > So we might never get events for failed/transitioning paths, however, > these are precisely the cases which we're interested in ... And, in fact, if paths go down due to e.g. an FC switch failure, it is common for a large number of paths to go down at once, causing a large number of uevents to be queued. > > > 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. > > > Which, thankfully, doesn't apply as multipathd will be polling the sysfs > attribute directly :-) > > Cheers, > > Hannes -- 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
