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 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 -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
