On Wed, Mar 10, 2021 at 11:15:38AM +0100, mwilck@xxxxxxxx wrote: > From: Martin Wilck <mwilck@xxxxxxxx> > > The message > > 3600a098000aad73f00000a3f5a275dc8: adding new path sdc > > was meant to warn users in cases where multipathd hadn't obtained > information about a path device from udev, and found it later > in some multipath map. In regular operation, this may indicate > a problem with the udev db, stuck udev workers, or some race > between udev and multipathd. It could also be a normal situation, > e.g. after switching from the initrd to the root FS. > > However, there's one mode of operation where this situation is normal: > the "check usable paths" mode (-C/-U). For performance reasons, multipath > doesn't do a full path discovery in this mode. It just reads the given > map. Thus encountering paths which aren't in pathvec is totally normal, > and will cause the above message for every path on every uevent for > a multipath device, which is highly confusing for users. > > Reduce the log level of this message to 3. I think that's sufficient. > The reason I'd set it originall to level 2 was mainly that when I > worked on that code, I really didn't want to miss any of these messages. Reviewed-by: Benjamin Marzinski <bmarzins@xxxxxxxxxx> > --- > libmultipath/structs_vec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libmultipath/structs_vec.c b/libmultipath/structs_vec.c > index 47b1d03..57cd88a 100644 > --- a/libmultipath/structs_vec.c > +++ b/libmultipath/structs_vec.c > @@ -192,7 +192,7 @@ bool update_pathvec_from_dm(vector pathvec, struct multipath *mpp, > must_reload = true; > continue; > } > - condlog(2, "%s: adding new path %s", > + condlog(3, "%s: adding new path %s", > mpp->alias, pp->dev); > store_path(pathvec, pp); > pp->tick = 1; > -- > 2.29.2 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
