[dm-devel] [PATCH v2 0/9] multipathd: remove udev settle dependency

[Martin Wilck]

On Wed, 2021-11-17 at 15:21 -0600, Benjamin Marzinski wrote:
> So, it turns out that commit 4ef67017 "libmultipath: add
> update_pathvec_from_dm()" already does most of the hard work of
> making
> multipath handle the uninitialized paths that exist during boot,
> after
> the switch root, but before the all the coldplug uevents have been
> processed. The only problem is that this code leaves the paths in a
> partially initialized state, which doesn't completely get corrected
> until a reconfigure happens.
> 
>  [...]
>
> I've tested these patches both by rebooting with necessary and
> unnecessary multipath devices in the initramfs and multipathd.service
> set to make multipathd start up at various points after the switch
> root,
> and by manually sending remove uevents to unintialize some paths, and
> then starting multipathd to test specific combinations of path
> states.
> But more testing is always welcome.

My late testing has revealed an issue with this patch with explicit
ALUA. It's similar to what you solved with the "ghost_delay" parameter
in the past.

With this patch, multipathd now starts before SCSI device detection
begins, and as soon as multipathd sets up a map, I/O on this map may be
started. With arrays supporting Active/optimized and Active/non-
optimized states and explicit ALUA, this causes unnecessary path state
switching if paths in non-optimized state are detected before optimized
ones. I/O will cause scsi_dh_activate() to be called in the kernel, and
this will run an STPG, which always uses active/optimized as target
state.

With RDDAC, we'll have a similar problem. The other device handlers
don't distinguish active and optimal states, AFAICS.

I fear this behavior will not be welcome in some configurations. So far
I haven't made up my mind how, and if at all, we can fix it. I suppose
something similar to ghost_delay would be possible on the multipath-
tools side, but it's not straightforward, because non-optimized paths
simply count as PATH_UP in multipathd. Also, the delay should probably
be much shorter than for PATH_GHOST. In my testing against a LIO
target, it was a matter of milliseconds which path would appear first.

Alternatively, maybe we can consider the way scsi_dh_activate() works?
Perhaps it doesn't have to switch from active/non-optimized to
active/optimized state? OTOH, there are other situation (explicit path
group switch) where we'd want exactly that.

The other alternative would be waiting for udev settle again. I'd
really like to avoid that.

Ideas and thoughts highly welcome.

Regards,
Martin