No Drive.Ata interface for NVME SSDs

[pothos]

Forwarding this bug from https://bugzilla.gnome.org/show_bug.cgi?id=778906

The model property is empty and there is no Drive.Ata interface for drives like INTEL SSDPEKKF256G7L or Samsung SSD 950 PRO 512GB.

[stove-panini]

Hello, I'm one of the reporters on the GNOME Bugzilla incident. Please let me know if I can offer any more information.

[boscowitch]

Dito, Im the original reporter, happy to provide more information too on the samsung model...

[vpodzime]

The model property is empty and there is no Drive.Ata interface for drives like INTEL SSDPEKKF256G7L or Samsung SSD 950 PRO 512GB.

The Drive.Model property being empty is a bug. But there's no Drive.Ata interface because NVME simply is not ATA.

[vpodzime]

@tasleson, would you mind trying to see what the problem with the Drive.Model property is? I know you have an NVME disk.

[pothos]

Ah, and the SMART related things are part of the ATA interface… That means there is no API yet to get SMART data.

[boscowitch]

smartctl /dev/nvme0 -a
works, so i guess a second case/api for nvme disks is needed.

[vpodzime]

smartctl /dev/nvme0 -a
works, so i guess a second case/api for nvme disks is needed.

Yes, but it shouldn't be Drive.ATA, but rather Drive.NVME.

[tasleson]

@vpodzime Sure I can look into the NVME property not working, which interface is this property on?

[vpodzime]

@vpodzime Sure I can look into the NVME property not working, which interface is this property on?

Drive

[tasleson]

@vpodzime Looks to me that this data is derived from the udev db and that the udev db doesn't have what we are looking for. Udev db dumps of NVME and another box that has a typical SATA disk:

P: /devices/pci0000:00/0000:00:1d.0/0000:3e:00.0/nvme/nvme0/nvme0n1
N: nvme0n1
S: disk/by-id/nvme-SAMSUNG_MZVKW512HMJP-000L7_S35BNX0J509280
S: disk/by-id/nvme-eui.002538c571b06a6d
S: disk/by-path/pci-0000:3e:00.0-nvme-1
E: DEVLINKS=/dev/disk/by-path/pci-0000:3e:00.0-nvme-1 /dev/disk/by-id/nvme-SAMSUNG_MZVKW512HMJP-000L7_S35BNX0J509280 /dev/disk/by-id/nvme-eui.002538c571b06a6d
E: DEVNAME=/dev/nvme0n1
E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/0000:3e:00.0/nvme/nvme0/nvme0n1
E: DEVTYPE=disk
E: ID_PART_TABLE_TYPE=dos
E: ID_PART_TABLE_UUID=18c29f08
E: ID_PATH=pci-0000:3e:00.0-nvme-1
E: ID_PATH_TAG=pci-0000_3e_00_0-nvme-1
E: ID_SERIAL=SAMSUNG MZVKW512HMJP-000L7_S35BNX0J509280
E: ID_SERIAL_SHORT=S35BNX0J509280
E: ID_WWN=eui.002538c571b06a6d
E: MAJOR=259
E: MINOR=0
E: MPATH_SBIN_PATH=/sbin
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: USEC_INITIALIZED=12280621

P: /devices/pci0000:00/0000:00:11.0/host0/target0:0:0/0:0:0:0/block/sda
N: sda
W: 43
S: block/8:0
S: disk/by-id/ata-Hitachi_HDS721010CLA332_JP2921HQ08NUDA
S: disk/by-id/scsi-SATA_Hitachi_HDS7210_JP2921HQ08NUDA
S: disk/by-path/pci-0000:00:11.0-scsi-0:0:0:0
S: disk/by-id/wwn-0x5000cca35dc3f11f
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:11.0/host0/target0:0:0/0:0:0:0/block/sda
E: MAJOR=8
E: MINOR=0
E: DEVNAME=/dev/sda
E: DEVTYPE=disk
E: SUBSYSTEM=block
E: ID_ATA=1
E: ID_TYPE=disk
E: ID_BUS=ata
E: ID_MODEL=Hitachi_HDS721010CLA332
E: ID_MODEL_ENC=Hitachi\x20HDS721010CLA332\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
E: ID_REVISION=JP4OA25C
E: ID_SERIAL=Hitachi_HDS721010CLA332_JP2921HQ08NUDA
E: ID_SERIAL_SHORT=JP2921HQ08NUDA
E: ID_ATA_WRITE_CACHE=1
E: ID_ATA_WRITE_CACHE_ENABLED=0
E: ID_ATA_FEATURE_SET_HPA=1
E: ID_ATA_FEATURE_SET_HPA_ENABLED=1
E: ID_ATA_FEATURE_SET_PM=1
E: ID_ATA_FEATURE_SET_PM_ENABLED=1
E: ID_ATA_FEATURE_SET_SECURITY=1
E: ID_ATA_FEATURE_SET_SECURITY_ENABLED=0
E: ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=232
E: ID_ATA_FEATURE_SET_SMART=1
E: ID_ATA_FEATURE_SET_SMART_ENABLED=1
E: ID_ATA_FEATURE_SET_AAM=1
E: ID_ATA_FEATURE_SET_AAM_ENABLED=0
E: ID_ATA_FEATURE_SET_AAM_VENDOR_RECOMMENDED_VALUE=128
E: ID_ATA_FEATURE_SET_AAM_CURRENT_VALUE=254
E: ID_ATA_FEATURE_SET_PUIS=1
E: ID_ATA_FEATURE_SET_PUIS_ENABLED=0
E: ID_ATA_FEATURE_SET_APM=1
E: ID_ATA_FEATURE_SET_APM_ENABLED=0
E: ID_ATA_DOWNLOAD_MICROCODE=1
E: ID_ATA_SATA=1
E: ID_ATA_SATA_SIGNAL_RATE_GEN2=1
E: ID_ATA_SATA_SIGNAL_RATE_GEN1=1
E: ID_ATA_ROTATION_RATE_RPM=7200
E: ID_WWN=0x5000cca35dc3f11f
E: ID_WWN_WITH_EXTENSION=0x5000cca35dc3f11f
E: ID_SCSI_COMPAT=SATA_Hitachi_HDS7210_JP2921HQ08NUDA
E: ID_PATH=pci-0000:00:11.0-scsi-0:0:0:0
E: ID_PART_TABLE_TYPE=dos
E: LVM_SBIN_PATH=/sbin
E: DEVLINKS=/dev/block/8:0 /dev/disk/by-id/ata-Hitachi_HDS721010CLA332_JP2921HQ08NUDA /dev/disk/by-id/scsi-SATA_Hitachi_HDS7210_JP2921HQ08NUDA /dev/disk/by-path/pci-0000:00:11.0-scsi-0:0:0:0 /dev/disk/by-id/wwn-0x5000cca35dc3f11f
E: UDISKS_PRESENTATION_NOPOLICY=0
E: UDISKS_PARTITION_TABLE=1
E: UDISKS_PARTITION_TABLE_SCHEME=mbr
E: UDISKS_PARTITION_TABLE_COUNT=2
E: UDISKS_ATA_SMART_IS_AVAILABLE=1

We have some custom code in the function udisks_linux_drive_update for mmc ref. (https://github.com/storaged-project/udisks/blob/master/src/udiskslinuxdrive.c#L781), so we could add another check for nvme, however IMHO I think what we should really probably look at is how we can get more information about the NVMe device populated into the udev database as there is much that is missing in comparison.

Notes: Udev db dump for NVME was on F26, other udev dump from RHEL6

[vpodzime]

however IMHO I think what we should really probably look at is how we can get more information about the NVMe device populated into the udev database as there is much that is missing in comparison

Absolutely. Plus udev database is the place others could gather the information from too. Having a custom code for that in udisks codebase is a wrong way to go.

[vpodzime]

Looks like there's not much we can do about this in udisks at this moment.

[sghosh151]

Is there a tracking bug on udev to include the NVMe data? What data should be there?

The kernel looks at NVMe as a new class of devices - independent of ATA or SCSI

P: /devices/pci0000:00/0000:00:1d.0/0000:02:00.0/nvme/nvme0
N: nvme0
E: DEVNAME=/dev/nvme0
E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/0000:02:00.0/nvme/nvme0
E: MAJOR=247
E: MINOR=0
E: SUBSYSTEM=nvme

When looking at an actual block device on NVMe - udev reports UDISKS_IGNORE=1. May be that is a place to start?

P: /devices/pci0000:00/0000:00:1d.0/0000:02:00.0/nvme/nvme0/nvme0n1/nvme0n1p1
N: nvme0n1p1
S: disk/by-id/nvme-Samsung_SSD_950_PRO_256GB_S2GLNX0H724537E-part1
S: disk/by-id/nvme-eui.0025385761b09f65-part1
S: disk/by-partlabel/EFI\x20System\x20Partition
S: disk/by-partuuid/526b503d-1973-49b8-9dae-910f907322d1
S: disk/by-path/pci-0000:02:00.0-nvme-1-part1
S: disk/by-uuid/2AE2-C5BA
E: DEVLINKS=/dev/disk/by-id/nvme-Samsung_SSD_950_PRO_256GB_S2GLNX0H724537E-part1 /dev/disk/by-id/nvme-eui.0025385761b09f65-part1 /dev/disk/by-partlabel/EFI\x20System\x20Partition /dev/disk/by-partuuid/526b503d-1973-49b8-9dae-910f907322d1 /dev/disk/by-path/pci-0000:02:00.0-nvme-1-part1 /dev/disk/by-uuid/2AE2-C5BA
E: DEVNAME=/dev/nvme0n1p1
E: DEVPATH=/devices/pci0000:00/0000:00:1d.0/0000:02:00.0/nvme/nvme0/nvme0n1/nvme0n1p1
E: DEVTYPE=partition
E: ID_FS_TYPE=vfat
E: ID_FS_USAGE=filesystem
E: ID_FS_UUID=2AE2-C5BA
E: ID_FS_UUID_ENC=2AE2-C5BA
E: ID_FS_VERSION=FAT16
E: ID_PART_ENTRY_DISK=259:0
E: ID_PART_ENTRY_NAME=EFI\x20System\x20Partition
E: ID_PART_ENTRY_NUMBER=1
E: ID_PART_ENTRY_OFFSET=2048
E: ID_PART_ENTRY_SCHEME=gpt
E: ID_PART_ENTRY_SIZE=1024000
E: ID_PART_ENTRY_TYPE=c12a7328-f81f-11d2-ba4b-00a0c93ec93b
E: ID_PART_ENTRY_UUID=526b503d-1973-49b8-9dae-910f907322d1
E: ID_PART_TABLE_TYPE=gpt
E: ID_PATH=pci-0000:02:00.0-nvme-1
E: ID_PATH_TAG=pci-0000_02_00_0-nvme-1
E: ID_SERIAL=Samsung SSD 950 PRO 256GB_S2GLNX0H724537E
E: ID_SERIAL_SHORT=S2GLNX0H724537E
E: MAJOR=259
E: MINOR=1
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: UDISKS_IGNORE=1
E: USEC_INITIALIZED=64898

[vpodzime]

When looking at an actual block device on NVMe - udev reports UDISKS_IGNORE=1. May be that is a place to start?

This only affects the HintIgnore property.

[vpodzime]

Is there a tracking bug on udev to include the NVMe data? What data should be there?

I'm not aware of any.

[hjmallon]

Hi, what is going on here or needed? I found the description a little confusing. I can look into this probably. Here is the systemd change for ID_MODEL on NVMe

systemd/systemd@e2c2d70#diff-27a09d9af06c9587b4302de923986a9d

Here is the change for ID_REVISION:

systemd/systemd@2c4370d#diff-27a09d9af06c9587b4302de923986a9d

They are both pretty recent but RedHat backported some of the udev NVMe changes to CentOS7 so maybe they will be backported?

[sl1pkn07]

Hi

any notice of this?

greetings

[tbzatek]

We're currently waiting for the first public release of https://github.com/linux-nvme/libnvme.

[hjmallon]

So libnvme rather than smartmontools? I understand that library is preferred over shelling out, but smartmontools has a lot more hardware support.

[tbzatek]

So libnvme rather than smartmontools? I understand that library is preferred over shelling out, but smartmontools has a lot more hardware support.

smartmontools is focused on SMART only, libnvme is focused on NVMe drive management. You're talking about #433.

[hjmallon]

smartmontools is focused on SMART only, libnvme is focused on NVMe drive management. You're talking about #433.

Correct, sorry :)

[sl1pkn07]

@tbzatek libnvme releases 1.0

https://github.com/linux-nvme/libnvme/releases/tag/v1.0