You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the tcm.py module, the various dump() functions return the VPD unit serial with the label "wwn"; which does not match the various /dev/disk/by-id/wwn-* entries set up by udev.
Udev can be coerced to making scsi_serial-* entries with an additional rules file, but...
Is there a reason that the VPD unit serial number is reported as the WWN in dump() (and hence targetcli)? (See also tcm.py:132: _get_wwn().)
Is there another way (without the sysfs hide-and-seek game) to match an rtslib backstore to a device in /dev/*/by-id ?
Thanks.
Notes:
If you know the vendor id that tcmu-runner assigns, and don't mind truncating the UUID serial number, you can, by eye, match the VPD unit serial number to the WWN. But it would be hard to codify this relationship in a robust way.
Not related to rtslib, but the tcmu-runner method of reading the WWN component appears very fragile: copying (unchecked) from the 28th byte of /sys/.../wwn/vpd_unit_serial. Yikes!
tcmu-runner/configfs.c:202: ret = asprintf(&ret_buf, "%s", &buf[28]);
A useful command (as used by udev) is, with example output from a tcmu-runner-backed drive:
Hi All,
In the tcm.py module, the various dump() functions return the VPD unit serial with the label "wwn"; which does not match the various /dev/disk/by-id/wwn-* entries set up by udev.
Udev can be coerced to making scsi_serial-* entries with an additional rules file, but...
Is there a reason that the VPD unit serial number is reported as the WWN in dump() (and hence targetcli)? (See also tcm.py:132: _get_wwn().)
Is there another way (without the sysfs hide-and-seek game) to match an rtslib backstore to a device in /dev/*/by-id ?
Thanks.
Notes:
If you know the vendor id that tcmu-runner assigns, and don't mind truncating the UUID serial number, you can, by eye, match the VPD unit serial number to the WWN. But it would be hard to codify this relationship in a robust way.
Not related to rtslib, but the tcmu-runner method of reading the WWN component appears very fragile: copying (unchecked) from the 28th byte of /sys/.../wwn/vpd_unit_serial. Yikes!
tcmu-runner/configfs.c:202: ret = asprintf(&ret_buf, "%s", &buf[28]);
A useful command (as used by udev) is, with example output from a tcmu-runner-backed drive:
Note the relationship between ID_SCSI_SERIAL from VPD 0x83, and the ID_WWN*.
The text was updated successfully, but these errors were encountered: