On 11/08/2016 08:56 PM, Benjamin Marzinski wrote:
I'm looking through the multipath udev rules again to see if we can come
closer to one consistent set, or at least understand why we need to
agree to disagree and right now I'm trying to figure out why it's
important for SUSE to have 56-multipath.rules run before
60-persistent-storage.rules.
We use 62-multipath.rules in RHEL for two main reasons. First, scsi_id
is run in 60-persistent-storage.rules, which is what sets ID_SERIAL, so
if multipath.rules is run before that, we'll never be able to get our
information from udev. I know that you've added code to cope with this,
assuming the standard uid_attribute, but it seems better to me to just
wait for udev to fill in these values itself.
Second, 60-persistent-storage.rules runs blkid, which should set
ID_FS_TYPE. Setting it in 56-multipath.rules just means that
60-persistent-storage.rules will overwrite it.
So, what do we gain by running multipath.rules before
60-persistent-storage.rules?
Yeah, it's slightly inconsistent.
Actually we are using the rules from sg3_utils (55-scsi-sg_id.rules and
58-scsi-sg3_symlink.rules), which will set ID_SERIAL prior to calling
56-multipath.rules.
Hence it works for us :-)
The main idea here is to deprecate scsi_id, with the goal of eventually
dropping it from systemd/udev.
However, the idea of this particular placement is precisely that we do
_not_ call scsi_id and blkid in 60-persistent-storage.rules for any
devices which are found to be part of a multipath device.
Doing so would not only give pointless information, but also there's a
fair chance that it wouldn't get you any information whatsoever in the
case of standby paths or during failover.
Or even stall the entire rule as it's stuck doing I/O.
My plan is to split off the call to 'scsi_id' from
60-persistent-storage.rules, (eg to 56-scsi-scsi_id.rules), and my
multipath to 57.
Then we would have:
55-scsi-sg_id.rules
56-scsi-scsi_id.rules
-> ID_SERIAL is set from this point on
57-multipath.rules
58-sg3_symlink.rules
60-persistent-storage.rules
and then everything would be far more consistent.
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@xxxxxxx +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
