[dm-devel] Improve processing efficiency for addition and deletion of multipath devices

[Benjamin Marzinski]

On Tue, Nov 29, 2016 at 08:57:18AM +0100, Martin Wilck wrote:
> On Mon, 2016-11-28 at 12:46 -0600, Benjamin Marzinski wrote:
> > On Thu, Nov 24, 2016 at 10:21:10AM +0100, Martin Wilck wrote:
> > > 
> > > from the udev db. Therefore IMO we just have to look at the last
> > > received event for a given path:
> > > 
> > >  - DELETE => discard the device
> > >  - ADD => use the udev properties coming with the event
> > >  - CHANGE => query udev db for current set of properties
> > 
> > The issue is that when we get a change event, there may be udev
> > environment variables that tell us what that specific event is for.
> > For
> > instance, a change in the Read-only status of the path device. Future
> > change events will not have those environment variables set.
> 
> And the udev db will not have records of the environment variables of
> previous change events? IOW, in your example, we can't derive the read-
> only status of a device by looking at the current set of udev
> properties of the device, only by tracking the full uevent history?

Correct, when a device's read only status is changed, the kernel will
send a change uevent with the udev environment variable "DISK_RO=<n>"
where <n> is 1 if the device changed to read-only, and 0 if it changed
to read-write.  This environment variable is only set for this change
event.

Now, it's totally possible that in every call to uev_update_path,
multipathd could check a device's read-only status in sysfs and take
action if it had changed. Otherwise, it needs to look though all the
change events in the batch it is processing to see if any of them have
the DISK_RO evironment variable set, and it would need to pass this
information to uev_update_path. I personally favor this second approach.
I can easily imagine multipath wanting to deal a specific way with
certain change events, especially if we go the route of ignoring dm
events completely, and relying only on uevents for updating multipath.
In these cases, it may not always be possible to look in sysfs to find
out what caused a previous change event, and we would have to read the
uevent environment variables for all the events we are processing.

-Ben

> 
> Regards
> Martin
> 
> -- 
> Dr. Martin Wilck <mwilck at suse.com>, Tel. +49 (0)911 74053 2107
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)