On Tue, 2022-12-13 at 22:35 +0100, Martin Wilck wrote: > On Tue, 2022-12-13 at 11:50 -0600, Benjamin Marzinski wrote: > > On Tue, Dec 13, 2022 at 08:46:28AM +0100, Martin Wilck wrote: > > > On Tue, 2022-12-06 at 18:37 -0600, Benjamin Marzinski wrote: > > > > > > > is set to "smart", the common case will still be > > > > that > > > > the device is in the wwids file, so we know that it's valid. I > > > > don't > > > > see > > > > a reason to do this check in that case. I was thinking that > > > > for > > > > the > > > > "smart" case, this check should go at the end of the function, > > > > before > > > > we > > > > return PATH_IS_MAYBE_VALID. Or do you have a reason why we > > > > should > > > > do > > > > it > > > > here that I'm missing? > > > > > > I'd argue the other way around: if the device is in use, it > > > doesn't > > > matter any more whether or not it's listed in the WWIDs file. > > > This > > > situation can only occur if something went wrong beforehand (most > > > probably, an inconsistent WWIDs file in the initrd, or some other > > > component misbehaving). If we tag such a device VALID although > > > it's > > > mounted, we'll almost certainly fall into emergency mode, > > > regardless of > > > the find_multipaths mode we're in. The reason is that multipathd > > > will > > > fail to map the mounted device, and systemd will consider the > > > path > > > device unusable, leading to the device being inaccessible either > > > way. > > > > Sure. We can leave it like this. I don't have strong opinions one > > way > > or > > the other. > > Thanks. > > Next step is: I provide this to the partner for testing who observed > the issues described in the commit message. I will only push this > upstream if we find it to be helpful. > > Martin Tests have shown that this patch indeed stabilizes booting on a very large system with "greedy" mode and a non-blacklisted non-multipath root disk a lot, without causing measurable delays in uevent processing. I have also tested in on other systems without noticing regressions. I'll send a v3 and push it to "queue" when reviewed. Martin -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
