Closed Passion1121 closed 8 months ago
@Passion1121, not sure why you closed this issue, did you find a hardware problem maybe?
The name of the variable ID_SERIAL
is arguably historic, but hard to change for exactly that reason. The logic you observed in the udev rules tries to determine the "best" (aka most reliable) device identifier for any given device, and assign it to ID_SERIAL
. All modern SCSI devices should provide a NAA identifier of some sort.
I used the uid_attribute attribute in the configuration item to configure it to ID_WWN to temporarily circumvent this problem.
ID_WWN
, like ID_SERIAL
, is chosen by the udev rules by some heuristics which identifiers are "better" (i.e. more reliable / unique) than others. The only difference I am aware of is that for ID_SERIAL, unlike ID_WWN, historical non-NAA identifiers are taken into account (but they should have very low priority, lower than any NAA identifiers). Perhaps there's something wrong with your udev rule set.
The DEFAULT_UID_ATTRIBUTE field uses ID_SERIAL by default, which causes WWID inconsistency and the paths are aggregated into two disks. In the fc environment, I don’t know under what circumstances the ID_SERIAL triggered uses the T10 format. The original wwid of 30000000000333 became 1vendor_model_33303000.