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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
