On Thu, 2017-12-07 at 12:49 -0600, Benjamin Marzinski wrote: > However, it is possible to create a device with no paths, which means > the device cannot know which hwentry to use for its device > configuration. __setup_multipath() used to help with this via > extract_hwe_from_path(), which grabbed the hwentry from a path if the > multipath device didn't already have it set. This is now done both > when > paths are added or the map is updated, which means that > extract_hwe_from_path() runs before the device is configured in > setup_map() instead of after the table has already been loaded. This > is > a good thing. But because of this, it can't check the dmstate or the > pathgroup state. I don't believe it's necessary to care what state > the > path is in, especially now that we use libudev. The vendor and > product > information gets cached by libudev when the path device is first > added, > and should remain the same regardless of whether or not the device is > currently up. My version does try to take the hwe information from a > path in the PATH_UP state first, but this is mostly to satisfy the > paranoia of the old version. It just occured to me while reviewing this patch once more that this might cause problems if the path WWID changes, as recently discussed.Perhaps you should at least skip paths with the "wwid_changed" attribute? Regards, Martin -- Dr. Martin Wilck <mwilck@xxxxxxxx>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
