Re: [PATCHv8 20/23] scsi: Add 'access_state' attribute

[Ewan Milne <emilne@redhat.com>]

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