[dm-devel] [PATCH 5/7] multipathd: fully initialize paths added by update_pathvec_from_dm

[Benjamin Marzinski]

On Mon, Nov 08, 2021 at 04:55:37PM +0000, Martin Wilck wrote:
> On Mon, 2021-11-08 at 10:29 -0600, Benjamin Marzinski wrote:
> > On Fri, Nov 05, 2021 at 11:20:01PM +0000, Martin Wilck wrote:
> > > > 1: udev hasn't gotten an event for a device
> > > 
> > > I don't think we can detect this without listening for kernel
> > > uevents.
> > > And even if we listen to them, we could have missed some. udevd
> > > doesn't
> > > have an API for it, either, AFAIK.
> > 
> > Isn't this the most common INIT_PARTIAL case, where we are waiting
> > for
> > the coldplug uevent? If there is no database file when we are
> > processing
> > the device, we are in this state. Correct? 
> 
> Not necessarily. udev may have got an event, but not have finished
> processing it, or failed to process it entirely (e.g. because of a
> timeout, your case 2.). When udevd sees an "add" or "change" event for
> a device for the first time, creating the db entry is the last action
> it takes. During coldplug, udevd will receive a lot of events almost
> simultaneously, but it may take considerable time until it has
> processed them all.

Fair enough. So if the first uevent hasn't completed already
successfully, it's gonna be hard to know why.
 
> > > > 2: udev got an event but timed out or failed while processing it
> > > 
> > > This would be the USEC_INITIALIZED case, IMO
> > 
> > If udev has, in the past, successfully processed an event for a
> > device,
> > but fails while processing a later uevent, it doesn't keep th data
> > from
> > the previous event. So it could lose the uid_attribute. But the
> > database file should still exist. Correct?
> 
> That's true. But we can't do anything about it. libudev will return
> what the database currently contains, which is the content from the
> last successfuly processed "add" or "change" uevent, whether or not
> other uevents are in the queue or being processed. I don't think this
> scenario matters in the current discussion about partially initialized
> paths. This is the "changed wwid" scenario which I think we handle
> quite nicely today already. Or am I misunderstanding?

If both events occurred before multipathd started up, then this wouldn't
simply be a "changed WWID".  The hope is to be able to reliably
distinguish this from case 3, where the data from udev is fine, but the
uid_attribute still isn't there.

-Ben

> Cheers,
> Martin