Proxmox - Serial number for "disks" incorrect

Hello all,

I recently spun up a server node with a fresh installation of Proxmox however, when I tried to build out a ZFS pool of 10 drives I would get an error. When I sorted by “Serial”, in the GUI, the disk serial numbers are the same between 4 of the drives (highlighted in red). Why is the serial the same between these particular drives?

For a more granular exploration to the problem I decided to SSH into the server and ran the following command:

root@Newton:~# udevadm info -p 'block/sdc' --query  all
P: /devices/pci0000:00/0000:00:02.2/0000:02:00.0/host0/target0:0:2/0:0:2:0/block/sdc
N: sdc
L: 0
S: disk/by-path/pci-0000:02:00.0-scsi-0:0:2:0
S: disk/by-id/wwn-0x502b2a201d1c1b1a
S: disk/by-id/scsi-3502b2a201d1c1b1a
E: DEVPATH=/devices/pci0000:00/0000:00:02.2/0000:02:00.0/host0/target0:0:2/0:0:2:0/block/sdc
E: DEVNAME=/dev/sdc
E: DEVTYPE=disk
E: DISKSEQ=11
E: MAJOR=8
E: MINOR=32
E: SUBSYSTEM=block
E: USEC_INITIALIZED=5697461
E: ID_SCSI=1
E: ID_VENDOR=ATA
E: ID_VENDOR_ENC=ATA\x20\x20\x20\x20\x20
E: ID_MODEL=KINGSTON_SA400S3
E: ID_MODEL_ENC=KINGSTON\x20SA400S3
E: ID_REVISION=0004
E: ID_TYPE=disk
E: ID_SERIAL=3502b2a201d1c1b1a
E: ID_SERIAL_SHORT=502b2a201d1c1b1a
E: ID_WWN=0x502b2a201d1c1b1a
E: ID_WWN_WITH_EXTENSION=0x502b2a201d1c1b1a
E: ID_SCSI_SERIAL=50026B728234D063
E: ID_BUS=scsi
E: ID_PATH=pci-0000:02:00.0-scsi-0:0:2:0
E: ID_PATH_TAG=pci-0000_02_00_0-scsi-0_0_2_0
E: DEVLINKS=/dev/disk/by-path/pci-0000:02:00.0-scsi-0:0:2:0 /dev/disk/by-id/wwn-0x502b2a201d1c1b1a /dev/disk/by-id/scsi-3502b2a201d1c1b1a
E: TAGS=:systemd:
E: CURRENT_TAGS=:systemd:

It seems as though Proxmox uses the ‘ID_SERIAL_SHORT’ field to populate the ‘Serial’ info in the GUI. My question is, how do I fix this issue with /sdc, /sdj, /sdm, and /sdn with the same serial number?

So I decided to do some more digging and output the serials for /sdc, /sdj, /sdm, and /sdn. Is this potentially a firmware issue with the following Kingston SSDs or a bug with Proxmox?

root@newton:~# echo /dev/sdc;udevadm info -p block/sdc --query all|grep ID_SERIAL
/dev/sdc
E: ID_SERIAL=3502b2a201d1c1b1a
E: ID_SERIAL_SHORT=502b2a201d1c1b1a
root@newton:~# echo /dev/sdj;udevadm info -p block/sdj --query all|grep ID_SERIAL
/dev/sdj
E: ID_SERIAL=3502b2a201d1c1b1a
E: ID_SERIAL_SHORT=502b2a201d1c1b1a
root@newton:~# echo /dev/sdm;udevadm info -p block/sdm --query all|grep ID_SERIAL
/dev/sdm
E: ID_SERIAL=3502b2a201d1c1b1a
E: ID_SERIAL_SHORT=502b2a201d1c1b1a
root@newton:~# echo /dev/sdn;udevadm info -p block/sdn --query all|grep ID_SERIAL
/dev/sdn
E: ID_SERIAL=3502b2a201d1c1b1a
E: ID_SERIAL_SHORT=502b2a201d1c1b1a
root@newton:~#

UPDATE:

Problem solved! I was able to get in touch with the folks over at Kingston and learned the serial numbers are more or less a revision number or batch number not an individually unique serial number. However, using their “SSD Manager” software (SSD Manager - Monitor Drive Health and Usage - Kingston Technology) you can update the firmware. Also something important to point out, to anyone potentially using an A400 series SSD in a ZFS or RAID array configuration it is not recommended because these are simply consumer grade architecture and not enterprise. Below you can see this is the case in my test environment:

ID_MODEL=KINGSTON_SA400S3

Kingston recommends using their enterprise disks such as the KC400 series for high IO applications. Hope this helps someone down the road.