[dm-devel] [PATCH] udev: create symlinks and watch even in suspended state

[Peter Rajnoha]

On Sat 29 Jan 2022 21:46, Martin Wilck wrote:
> On Sat, 2022-01-29 at 21:05 +0100, Zdenek Kabelac wrote:
> > Dne 29. 01. 22 v 0:21 Martin Wilck napsal(a):
> > 
> > > 
> > > AFAICS my patch eliminates the window for this error entirely.
> > 
> > 
> > Ok now I see that there is already skip for DM_SUSPENDED
> > and you patch likely only tries to preserve some existing state of
> > links.
> > 
> > I'll need to get in touch with Peter here.
> > 
> > I guess the idea behind was to avoid read of device that will be
> > resumed and 
> > will automatically get a new event - and suspened device itself
> > cannot change 
> 
> Thank you!
> 
> > - but that fact it's been loosing existing state was missed - I'm
> > wondering 
> > why this was not seen as problem before.
> 
> One reason is that we're now starting multipathd earlier. This has a
> lot of advantages, but it reveals problems that were hidden behind the
> "After=systemd-udev-settle.service" dependency of mulltipathd before.

Hi!

(just discussed this with Zdenek too)

The patch makes sense to me!

We added all the DM_UDEV_PRIMARY_SOURCE_FLAG and related for exactly
such cases where we need to take the existing values already scanned
in previous event, main use-case being the trigger at boot. We just
didn't cover the 13-dm-disk.rules with the same logic regarding the
suspended state to keep the symlinks - I didn't think it would cause
issues (because, usually, after suspend, we anticipate incoming
resume where the device is scanned again).

But yes, if temporarily losing the symlink causes issues, your patch
solves that (Zdenek will push that upstream).

(There's one more situation with checking the suspended state for the
pvscan we have in 69-dm-lvm...rules, but that's lvm-specific, we'll
patch that one...)

Thanks!

-- 
Peter