Problems getting WWID recognized

[Albert Chin]

On Wed, Aug 26, 2020 at 02:11:25PM -0300, Rafael David Tinoco wrote:
> So, you see... your ID_SERIAL is coming from:
> 
>       Vendor Specific Identifier Extension: 0x11ff54b6b7820049
> 
> from VPD page 0x83

Coming back to this after a hiatus. I was reading through the email
exchange we had and while the Solaris iSCSI server might not be
responding correctly to VPD page 0x80, as long as ID_SERIAL in udev is
populated and uid_attribute is set to ID_SERIAL in multipath.conf, why
shouldn't "multipath -v4 -ll" output the correct device serial id
rather than:
  # multipath -v4 -ll 2>&1 | egrep 'sd.: serial'
  Aug 24 16:00:01 | sda: serial = 00d4e61f3aa6f0ca26002b133720844a
  Aug 24 16:00:01 | sdc: serial =
  Aug 24 16:00:01 | sdd: serial =
  Aug 24 16:00:01 | sdm: serial =
  Aug 24 16:00:01 | sdn: serial =
  Aug 24 16:00:01 | sdo: serial =

According to multipath.conf(5):
  uid_attribute    The udev attribute providing a unique path identifier
                   (WWID).  If  uid_attribute is set to the empty string,
                   WWID determination is  done  using  the  sysfs method
                   rather then using udev (not recommended in production;
                   see WWID generation below).

                   The default is: ID_SERIAL, for SCSI devices

                   The default is: ID_UID, for DASD devices

                   The default is: ID_WWN, for NVMe devices

  property         Regular  expression  for an udev property. All devices
                   that  have  matching  udev  properties  will be   ex‐
                   cluded/included.  The handling of the property keyword
                   is special, because devices must  have  at least  one
                   whitelisted  udev  property; otherwise they're treated
                   as blacklisted, and  the  message "blacklisted,  udev
                   property missing" is displayed in the logs.

And we have the following in multipath.conf:
  defaults {
    path_selector "round-robin 0"
    user_friendly_names no
    path_grouping_policy multibus
    rr_min_io_rq 1
    rr_weight priorities
    features "1 queue_if_no_path"
    uid_attribute "ID_SERIAL"
    verbosity 6
  }

  blacklist_exceptions {
    property "ID_SERIAL"
    wwid  ...
    ...
  }

It would seem like the udev ID_SERIAL property is irrelevant to
multipath. Indeed, looking at just sda:
  # sg_inq -e --page=0x80 /dev/sda
  VPD INQUIRY: Unit serial number page
    Unit serial number: 00d4e61f3aa6f0ca26002b133720844a

  # sg_vpd --page=sn /dev/sda
  Unit serial number VPD page:
    Unit serial number: 00d4e61f3aa6f0ca26002b133720844a

  # udevadm info --query=all --path /sys/block/sda | egrep ID_SERIAL       
  E: ID_SERIAL=3644a842037132b0026caf0a63a1fe6d4
  E: ID_SERIAL_SHORT=644a842037132b0026caf0a63a1fe6d4

  # multipath -v4 -ll 2>&1 | egrep 'sda: serial'
  Aug 24 16:00:01 | sda: serial = 00d4e61f3aa6f0ca26002b133720844a

If multipath identifies the sda serial as
00d4e61f3aa6f0ca26002b133720844a, this could only have come from the
sq_inq/sg_vpd inquiry, making udev useless and the modification of any
udev rule to help futile.

> > # /lib/udev/scsi_id --whitelisted --device=/dev/sdc
> > 3600144f0f4e106e711ff54b6b7820049
> 
> > > > # sg_inq -e /dev/sdc
> > > > VPD INQUIRY, page code=0x00:
> > > >    Supported VPD pages:
> > > >      0x0        Supported VPD pages
> > > >      0x80       Unit serial number
> > > >      0x83       Device identification
> > > >      0x86       Extended INQUIRY data
> > > >      0xb0       Block limits (sbc2)
> > > >      0xb2       Logical block provisioning (sbc3)
> > > >
> > > > # sg_inq -e --page=0x80 /dev/sdc
> > > > VPD INQUIRY: Unit serial number page
> > > >   Unit serial number:
> > >
> > > Could you try 0x80, 0x83, 0x86 as well ? Nothing there ? If there is
> > > SERIAL coming from your storage server, it is not behaving like
> > > described by SCSI SBC-4 standards.. but you could create a wrapper
> > > to be executed by udev (check bcache-tools package udev rules) that
> > > could get something else from your storage server and define it as
> > > ID_SERIAL.
> >
> > # sg_inq -e --page=0x83 /dev/sdc
> > VPD INQUIRY: Device Identification page
> >   Designation descriptor number 1, descriptor length: 20
> >     designator_type: NAA,  code_set: Binary
> >     associated with the Addressed logical unit
> >       NAA 6, IEEE Company_id: 0x144f
> >       Vendor Specific Identifier: 0xf4e106e7
> >       Vendor Specific Identifier Extension: 0x11ff54b6b7820049
> >       [0x600144f0f4e106e711ff54b6b7820049]
> >   Designation descriptor number 2, descriptor length: 71
> >     transport: Internet SCSI (iSCSI)
> >     designator_type: vendor specific [0x0],  code_set: ASCII
> >     associated with the Target port
> >       vendor specific: iqn.2010-09.org.openindiana:02:4a7b9f0f-4777-631e-e19a-fb0b94963439
> >   Designation descriptor number 3, descriptor length: 8
> >     designator_type: Target port group,  code_set: Binary
> >     associated with the Target port
> >       Target port group: 0x0
> >   Designation descriptor number 4, descriptor length: 8
> >     designator_type: Relative target port,  code_set: Binary
> >     associated with the Target port
> >       Relative target port: 0x2
> 
> Try installing sg3-utils and check if rules from 55-scsi-sg3_id
> satisfy your need. I'm aware that the rules file takes both VPDs into
> consideration for the ID_SERIAL.  Only thing left to try, if that does
> not work, is to open a bug against systemd-udev:
> 
> $ dpkg -S /lib/udev/rules.d/60-persistent-storage.rules
> udev: /lib/udev/rules.d/60-persistent-storage.rules
> 
> then let me know the bug #. I can't guarantee a fix but I'll make sure
> to look into it for the next development cycle (as for this one we are
> close to freeze date). Meanwhile you will be able to get a rules entry
> that works for your case as a workaround.
> 
> Cheers o/
> 
> -- 
> ubuntu-users mailing list
> ubuntu-users at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users

-- 
albert chin (china at thewrittenword.com)