Fix for drive serials showing up as duplicates by certain controllers (solution included)

[genecc]

Hello,

 

I have identified an issue that seems to affect my USB enclosure which uses a Jmicron USB bridge (ID 152d:0567 JMicron Technology Corp.)

This causes unRAID to see all disks in the enclosure as having the same serial number. After some troubleshooting, I was able to determine that this was because udev was not able to obtain the serials through the ata_id utility.

 

After much finagling, I was able to compile a patched version of ata_id and upon replacing it, the disks now correctly show up with unique serials.

 

This was fixed upstream quite a while ago, but never made it into the Slackware distro:

https://github.com/systemd/systemd/issues/2362

 

The patch itself is quite small:

https://github.com/harendra-kumar/systemd/commit/75feb52379f80c3df354b85d1df3274fdde5fccd

 

I'd love to see this included in the latest version of unRAID if possible! Otherwise please point me in the right direction as to how I should properly override the /lib/udev/ata_id file. It needs to be quite early in the boot process before udev triggers, otherwise I need to retrigger udev and start the array every time.

 

I compiled a patched version of ata_id and added an install script that triggers udev in my /boot/extra directory, and it correctly passes the serial numbers through after the fix.

 

---

 

Demonstration of issue:

 

When I put my two drives in my DAS, udev cannot distinguish between any of my drives even though they have unique serials. Same thing happens with assigned drives.

 

 

# udevadm info --query=all --name=/dev/sdb | grep -i serial
E: ID_SERIAL=Samsung_SSD_850_EVO_500G_202006054D01-0:1
E: ID_SERIAL_SHORT=202006054D01

# udevadm info --query=all --name=/dev/sda | grep -i serial
E: ID_SERIAL=Samsung_SSD_850_EVO_500G_202006054D01-0:0
E: ID_SERIAL_SHORT=202006054D01

 

However, hdparm -I correctly identifies the disks uniquely:

# hdparm -I /dev/sda | grep -i serial
        Serial Number:      S3PTNF0JXXXXXX0
# hdparm -I /dev/sdb | grep -i serial
        Serial Number:      S3PTNF0JXXXXXX1

 

 

[ChatNoir]

Seeing the two unique serial numbers you provide, it seems like a simple increment from a base value, not linked to the actual drive S/N.

 

I wonder what happens if you change a drive. Lets say you replace the drive from the second emplacement, would it have also the S/N S3PTNF0JXXXXXX1 ?

[genecc]

2 hours ago, ChatNoir said:

Seeing the two unique serial numbers you provide, it seems like a simple increment from a base value, not linked to the actual drive S/N.

 

I wonder what happens if you change a drive. Lets say you replace the drive from the second emplacement, would it have also the S/N S3PTNF0JXXXXXX1 ?

 

Those are anonymized. The Xs (and 0/1) are unique values. They aren’t actually just one off. 

 

Edited January 29, 2021 by genecc

[jjlinus]

Complete Unraid novice here...having the same issue with a batch of USB-enclosures showing up with the same identification. 'JMicron_Generic_0123456789ABCDEF-0:0'

Not sure what steps to take as I currently lack the knowledge to modify-run custom scripts etc. Any simple step-by-step instructions would be greatly appreciated.

[trurl]

There are other problems besides just this one when trying to use USB for array or pool so not recommended even if you could get past this one issue 

[Howboys]

I'm also seeing this with 2 different enclosures. Each drive is recognized and the Identity part of the disk reads the correct serial/model/smart. But the Main page only shows drives like JMicron_Generic_0123456789ABCDEF-0:0.

 

This is mostly fine except preclear freaks out (clicking preclear only seems to kick off the operation on the first drive regardless of which button you press).

 

I would really love a solution to this.

[trurl]

On 11/4/2022 at 2:39 AM, trurl said:

There are other problems besides just this one when trying to use USB for array or pool so not recommended even if you could get past this one issue 

 

[Kilrah]

6 minutes ago, trurl said:

 

Nobody here has talked about using them for the array or pools.

It's still convenient to be able to connect multiple UDs for preclears and things and if there is a way to get some that are currently not being differentiated and thus not usable at the same time to be able to it would be positive.

[Howboys]

1 hour ago, trurl said:

 

 

Okay I get that but just blurting out the same message isn't really helpful.

 

There's a bug here - the USB controller is reporting the right information but unraid isn't receiving it correctly.

 

But since you seem to be an expert on USB interfaces: what are the other problems exactly?

[trurl]

5 hours ago, Howboys said:

what are the other problems exactly?

Disconnects. When an array disk disconnects, it will have to be rebuilt since it will become out-of-sync with the array. If used in a single disk pool, or an array without parity, this is less a problem since there is nothing to keep in sync.

 

No SMART reports from some USB, making it impossible for Unraid to monitor disk health.

 

Inconsistent identification from some USB, making it impossible for Unraid to accurately track drive assignments in array or pools.