phillxnet
October 18, 2017, 8:56am
2
@Ivan Nice find; and a belated welcome to the Rockstor community.
Thanks for sharing your solution here.
On a related note we had a bit of a job getting nvme device’s partitions recognised as they have a rather unique naming scheme, see @f_l_a and my discussion on this in the following forum thread:
[image]
which in turn also links to:
Hi together,
I have installed the rockstor onto my nvme device and rockstor logs the following line every minute when checking the disk state:
[04/Jun/2016 13:32:26] ERROR [smart_manager.data_collector:342] Failed to update disk state.. exception: object of type 'NoneType' has no len()
[04/Jun/2016 13:33:27] ERROR [storageadmin.util:46] request path: /api/disks/scan method: POST data: <QueryDict: {}>
[04/Jun/2016 13:33:27] ERROR [storageadmin.util:47] exception: object of type 'NoneType' has n…
where @snafu developed the needed (at the time) udev rules to surface the required unique serial number and helped with diagnosing the naming issues our code originally failed to understand:
opened 12:09PM - 16 Jul 16 UTC
closed 01:09AM - 19 Jul 16 UTC
enhancement
Thanks to @snafu in the following forum thread for helping to diagnose an nvme c… ompatibility bug affecting installs where the system disk is an nvme device. This in part involves dealing with the as yet unaccounted for naming conventions for these devices.
Please update the following forum thread on significant development with this issue:
https://forum.rockstor.com/t/unable-to-update-disk-state-for-nvme-device/1567
and it’s pr:
rockstor:master ← phillxnet:1397_improve_nvme_compatibility_for_system_disk
opened 01:06PM - 17 Jul 16 UTC
As nvme device names differ in format from previously accounted for devices the … root_disk() method failed to properly return the base device name of a partition ie:
base device name = nvme0n1
Rockstor system partition on the above base device:
3rd partition = nvme0n1p3
This lead to an unintentional return of the base device from scan_disks() as a device of interest. This in turn lead to db issues where the system disk was represented twice, once as it's base device and again as the usual system disk partition entry.
The changes presented here have been tested on regular, bios raid, and mdadm system disk installs and no regressions were observed.
Fixes #1397
Thanks to @snafu in the following forum thread for helping to pinpoint this bug and for testing the changes presented here (to master) on an nvme system disk install by hand applying them to latest stable (3.8-14).
https://forum.rockstor.com/t/unable-to-update-disk-state-for-nvme-device/1567
Please note that this patch does not address outstanding serial retrieval issues for nvme devices however @snafu in the above referenced thread has developed a working set of udev rules towards the end of that thread.
It may be that udev since then has been updated, by upstream CentOS, to no longer make custom udev rules necessary. What is your experience with Rockstor’s current dealing with this, ie do you get any serial number warning on your Disks page?
Thanks for your contribution here, most valuable, especially as these (strangle dev named) devices become more popular.