search

rockstor / rockstor-core

Linux/BTRFS based Network Attached Storage(NAS)
http://rockstor.com/docs/contribute_section.html
GNU General Public License v3.0
552 stars 137 forks source link

use udev for device serial by default #1052

Open phillxnet opened 8 years ago

phillxnet commented 8 years ago

As the code is already in place for this but off by default (see #786) except where empty serial numbers are returned by lsblk (ie virtio and mmcblk devices) this code could be turned on by default for all devices in the testing channel. This could pave the way for a more radical move to replace lsblk entirely with udev funcions, ie @schakrava 20th August comment in above referenced pr.

phillxnet commented 8 years ago

Now that Rockstor as of 3.8-14.02 uses by-id names that are in turn created by udev it may make sense to switch over to only using udev for our device serial extraction, hence centralising our serial retrieval around get_disk_serial() in src/rockstor/system/osi.py, especailly given that by-id names are constructed by udev using a devices serial number as udev sees it.

Care should be taken here as the serial number of a device is the canonical reference used by Rockstor to track devices. However get_disk_serial() has been made to return the same serial as lsblk does, but this is obviously not universally tested so any move on changing the default here would have to be aware of this and happen at the earlier stages of a testing cycle.

A move to a more centralised serial retrieval such as get_disk_serial() by default may also allow for accounting for devices that require, at one time of another, special methods to retrieve a serial number. This has already been added as a 'personality' to the function to account for md devices having no udev serial by substituting their unique uuid within this function. Likewise maybe nvme devices serial retrieval could be added as a personality. See the following forum post on how specific nvme tools can be used to retrieve a serial number from these devices. Thanks to @f_l_a in the following forum thread for providing a potential work around until our upstream udev versions are new enough to account for these devices by default: https://forum.rockstor.com/t/retrieving-serial-from-nvme-device-fails/1686

Hooverdan96 commented 9 months ago

Is this still relevant, or have the underlying thing been addressed thus far? If yes, let's close this. Otherwise, it means that this is still relevant for 4.x/5.x developments

phillxnet commented 9 months ago

@Hooverdan96 Thanks for the Triage here. Re:

Is this still relevant

I believe so, and I've added this to our current testing channel. We should no longer resource both lsblk and udev our selves as it makes for additional complexity. And we do have some modernisation to do on this front re some more modern devices such as nvme types. So removing the lsblk serial retrieval entirely means we have a single source for serial again. And can then work from there going forward.

A much overdue development. Thanks for digging this one out from our excessive back-log (now significantly reduced via your ongoing actions currently :) ).

phillxnet commented 5 months ago

Adding an interesting issue relating to lsblk and it's fail-over re udev serial retrieval:

https://github.com/util-linux/util-linux/pull/1024

In some cases ID_SERIAL_SHORT isn't provided by libudev, but ID_SERIAL is. An example of this are virtio devices.

phillxnet commented 2 months ago

Removing from 5.1.x-x Milestone as we need to kick this down the road a little more. This way we can more properly abstract the serial retrieval to account for hdparm only serial retrievals for example. Or for nvme devices that need their own specific tool for serial retrieval. This work is more early to mid testing channel, and we are late testing now in the current Milestone.