Closed trgill closed 6 years ago
It looks like the two nvme drives on this system each have 2 entries, one of which has devnode and one which doesn't?
https://gist.github.com/agrover/c2b432e59a183fdf1f5c97ba7d2e2c1c
Maybe this means we need to be more precise about using udev to enumerate block devices. See also #908.
That entry in the gist at line 48 -- it's listed as SUBSYSTEM=block and DEVTYPE=disk but doesn't have DEVNAME (or any of the other tags we check for, ID_PART_TABLE_TYPE, ID_PART_ENTRY_DISK, ID_FS_USAGE). or MAJOR or MINOR set.
It also shares ID_WWN with the entry at line 84. This seems like some kind of container or controller device.
Should we be filtering these out?
I don't think that the udevadm output will reliably tell what device has a devnode and what doesn't. The devnode is obtained by a specific udevadm method, rather than by just looking up some udev property. Probably the cheapest way to find the true state of affairs is to run a query using pyudev.
It's showing us something that is SUBSYSTEM=block and DEVTYPE=disk that doesn't have a DEVNAME on this machine and appears to be a duplicate of another entry that looks much more usable. I'm sure there are other ways to lack a DEVNAME but this seems to be one that we can fix straight off. How should we fix this? Is this something we need to handle or is this a udev problem for thinking something is a disk when it really isn't?
Our tests fail on a system with an NVMe drive. The error message is:
thread 'engine::strat_engine::backstore::backstore::tests::real_test_setup' panicked at 'block devices have devnode', libcore/option.rs:914:5
The problem can be reproduced on dell-r730-011.dsal.lab.eng.rdu2.redhat.com