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@xxxxxxxx>, Tel. +49 (0)911 74053 2107 > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton > HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
