Manual addition of pool

magicalyak · October 28, 2020, 12:24pm

I have three fusionIO cards and they seem to not play that well with BTRFS and Rockstor. I made a pool with them and it imported and I can use it but, is there a hardcoded way to get around Rockstor complaining about the drives. It says they aren’t unique with serials but I think it’s because fusionio didn’t populate the ID_SERIAL fields. I can try to fake that but just wondering if there is a workaround or some steps for other storage situations like this?

phillxnet · October 28, 2020, 8:37pm

@magicalyak You may very well be able to setup a udev rule for this. But it must always assign the same serial to each drive. You then have the issue of uniquely identifying each drive which is exactly what a serial number is for! So I suggest seeing if this is just a matter of actually no serial, or if Rockstor is just failing to extract that serial.

In the early days we used to only use lsblk but that often fails to retrieve hardware serials so I popped in a udev fail over system. So it’s worth looking to see if that system can be enhanced to retrieve actual serials if the actually exist. Otherwise you are back to needing a serial number, or other unique factor, then then generate a serial. This is why udev itself doesn’t generate a by-id name for devices that don’t have a serial as by-id names have serials within them. I take it your devices don’t have by-id names?

Take a look at a serial attribution mechanism using udev in our bcache dev wiki:

And a search on forum very early posts has a udev to assign serials on some grounds or other.

But do make sure that this isn’t just a bug on our ability to retrieve the serials as that would be the first stop-off point obviously:

github.com

rockstor/rockstor-core/blob/897587beccb662838bb61be35568fd0728e03047/src/rockstor/system/osi.py#L1166-L1187


      
          def get_disk_serial(device_name, device_type=None, test=None):
              """Returns the serial number of device_name using udevadm to match that
              returned by lsblk. N.B. udevadm has been observed to return the following:-
              ID_SCSI_SERIAL  rarely seen
              ID_SERIAL_SHORT  often seen
              ID_SERIAL        thought to always be seen (see note below)
              N.B. if used in this order the serial is most likely to resemble that shown
              on the device label as well as that returned by the lsblk. ID_SERIAL seems
              always to appear but is sometimes accompanied by one or both of the others.
              When ID_SERIAL is accompanied by ID_SERIAL_SHORT the short variant is
              closer to lsblk and physical label. When they are both present the
              ID_SERIAL appears to be a combination of the model and the ID_SERIAL_SHORT
              --------- Additional personality added for md devices ie md0p1 or md126,
              these devices have no serial so we search for their MD_UUID and use that
              instead.
              :param device_name: eg /dev/sda as per lsblk output used in scan_disks()
              :param device_type: the lsblk TYPE for the given device eg: disk, crypt.
              The equivalent to the output of lsblk -n -o TYPE device_name. Defaults to
              None as an indication that the caller cannot provide this info.
              :param test: When not None this parameter's contents is substituted for the

This file has been truncated. show original

You will see from that comment section and code that we have a special case for md devices where by we substituting their MD_UUID (their virtual version of a hardware serial). It may be that your devices can be likewise treated. That would make for a ‘proper’ fix.

Care is taken in that procedure to replicate lsblk serial return behaviour but if your type of drives (sorry totally unfamiliar with fusionIO stuff). Otherwise there may be a facility to configure these cards to produce the required unique identifer that we can use. We basically need to identify a drive from another to manage drives, hence the serial dependency. See:

Hope that helps, at least with some pointers.