Serial number collision?

[Elixor]

Hello,
I bought three ssd to usb adapters (https://www.aliexpress.com/item/33034187646.html?spm=a2g0s.9042311.0.0.6cb04c4doK8A5N)
Before I will open dispute I would like to verify here with you if this is really problem of those adapters.

I have three SSD's connected to true nas PC in RAID. But I had to change connections. As replacement I choice Kebidu sata adapter mentioned above.
But when I try connect them to PC I can always see only one in time. I tryed to disconnect them and then connect one by one.
Strange is then one is connected and I connect another - the old is replaced by new. So I cant re-init RAID I have.

My guess it the problem is comming from same Serial number. Can serial number be generated by adapter by the way?
If I use for connect second disk another adapter (the old one), Raid is init (but ony with 2 disks, one is missing).

on the picture you can see what happend when I tryied to plug-in two disksk - maybe it say something.

Is there a way how mount disks in true nas with same serial number or the problem is somewhere else?
Thanks in advance

 

[joeschmuck]

I have three SSD's connected to true nas PC in RAID.

Explain what you mean by RAID? Are you trying to use a raid controller? If this is the case, stop and don't do that. If that isn't the case, I would be surprised that the USB adapter is causing the serial number to be duplicated.

Also please follow the forum rules and add your hardware specs and what version of TrueNAS you are running. It will help us provide fast and good feedback to you.

 

[Elixor]

Hello,

thank you for your reply and sorry for missing information. I will do my best to add them.
True nas version is: TrueNAS-12.0-U1.1

Explain what you mean by RAID? Are you trying to use a raid controller?

I bought 3 WD blue 4TB HDD's (https://www.amazon.com/WD-Blue-4TB-Hard-Drive/dp/B013HNYV8I/ref=cm_cr_arp_d_product_top?ie=UTF8)
then I connect them to my old laptop (https://www.itpro.co.uk/laptops/29981/dell-vostro-14-5468-review)
via USB port. Using HDD case what allowed me connect them via USB.
Everything was fine - all HDD's was detected and I created new pool and tank in True nas using all three disks in RAID-Z and everything was still fine.

But, then I replaced HDD cases by new "sata to usb adapters" I mentioned above with problem I described.

I would be surprised that the USB adapter is causing the serial number to be duplicated.

Me too but I cant see any other difference. As you can see on attached picture.
When I connect one HDD -> in True nas new disk appear with name DA0
When I connect second HDD -> in True nas DA0 disappear and new disk appear with name DA1

So there is never mounted more than one HDD. Only possible think I can see is some kind of collision in HDD serial number.
On the picture You can see first and second have same ID.

 

[Patrick M. Hausen]

Running a storage pool on disks via USB is not going to work. Simply don't do that.

If you still insist: every USB/SATA bridge may or may not come with their own specific way of presenting the disk drive to the host system. So if you write data on the disk using one adapter, it might be completely unreadable using another one. You would need to put the disks back in their cases or try different brands of adapters until you find one that "works". But there's nothing we can do to support you, sorry.

 

[Elixor]

Hello,
but issue is not that the disk is unreadable. They are readable but only one in time. True nas still refuse connect more than one in one moment from some reason. My point is and my true question is, if there could by some kind of serial number collisions.

 

[joeschmuck]

When I connect second HDD -> in True nas DA0 disappear and new disk appear with name DA1

Hum, where did you see that? I saw that you added DA0 and then added DA1. I never saw DA0 get removed but maybe it's going to be one of those days, I hope not as I have a major presentation to give later today.

 

[Patrick M. Hausen]

My point is and my true question is, if there could by some kind of serial number collisions.

There could be a "whatever" collision with the USB adapters you use. Obviously only one of them works at a time. About the cause one can only speculate - how should anyone tell? Ask the manufacturer/seller if they have such a limitation. Return them for working ones.

Trying not to be uncesserarily rude: what do you expect from people on this forum? You have some arbitrary unspecified USB-SATA hardware (which is not supported as a connection method, everybody will tell you that!) and now you are asking for what precisely? The disks worked with the USB bridges in their original cases. They don't work with these new adapters. Hence these adapters are most probably crap. There is nothing TrueNAS specific in here.

HTH anyway,
Patrick

 

[HoneyBadger]

My guess it the problem is comming from same Serial number. Can serial number be generated by adapter by the way?

I can see that in your initial screenshot - the da0 and da1 devices have the same S/N.

In all likelihood, I will bet that there is no unique identifier on the devices - even down to the silicon level - and the FreeNAS/TrueNAS system has no way to determine that it isn't the same device just unplugged and re-plugged. You can test this out under a different OS but I imagine a Linux system will have a similar problem and refuse to mount both at once. (Windows might just silently corrupt the data and tell you everything's fine.)

The other users are not incorrect though in their assessment that USB-to-SATA devices are not suitable for an active pool. They are fine to attach an SSD for a boot device, but nothing beyond that.*

*you can use one for L2ARC at your own risk, I don't recommend it, but at least an L2ARC device failing doesn't kill your pool

 

[Elixor]

Thank you for replies guys!

Hum, where did you see that? I saw that you added DA0 and then added DA1. I never saw DA0 get removed but maybe it's going to be one of those days, I hope not as I have a major presentation to give later today.

Unfortunately that DA1 was removed is not possible to see in console output. But I can see it in administration page in Disks section. Once I plug next disk, name is changed from DA0 to DA1. Its strange.

I can see that in your initial screenshot - the da0 and da1 devices have the same S/N.

In all likelihood, I will bet that there is no unique identifier on the devices - even down to the silicon level - and the FreeNAS/TrueNAS system has no way to determine that it isn't the same device just unplugged and re-plugged. You can test this out under a different OS but I imagine a Linux system will have a similar problem and refuse to mount both at once. (Windows might just silently corrupt the data and tell you everything's fine.)

The other users are not incorrect though in their assessment that USB-to-SATA devices are not suitable for an active pool. They are fine to attach an SSD for a boot device, but nothing beyond that.*

*you can use one for L2ARC at your own risk, I don't recommend it, but at least an L2ARC device failing doesn't kill your pool

I completely agree but I cant see how it is possible. I thought the S/N is generated by OS or as S/N is used some kind of unique identifier of HDD.
Do you think is possible that this S/N is loaded from Sata to usb hardware?
I know USB's are not good for this behavior. I am not building some extra-profesional NAS. I just want to store somewhere few of movies and photos from vacation. My old computer + truenas and few HDD's looks fine for this. But its a bit off-topic.
From my point of view this is interesting problem

 

[HoneyBadger]

I completely agree but I cant see how it is possible. I thought the S/N is generated by OS or as S/N is used some kind of unique identifier of HDD.
Do you think is possible that this S/N is loaded from Sata to usb hardware?
I know USB's are not good for this behavior. I am not building some extra-profesional NAS. I just want to store somewhere few of movies and photos from vacation. My old computer + truenas and few HDD's looks fine for this. But its a bit off-topic.
From my point of view this is interesting problem

For how it's possible - I hate to paint with a broad brush here, but back-alley manufacturers in Shenzhen are not exactly known for following standards or having decent quality assurance.

The serial number of the USB bridge should not be used - the device should be passing the serial number and other unique information of the connected SATA device through to the OS. But in your case, the serial number of the USB devices all appear to be identical - DD564198838AA to be exact.

And if you review the log lines, you'll see reference to GEOM_MULTIPATH - what FreeBSD is doing is seeing the same serial number on multiple connection paths. It's created a single multipath device of "disk1" with two means to get to it - via da0 and da1 - and if it actually was the same device, this would be correct. You'll see this in SAS drives that have both paths connected. But if it's not the same device, this opens up paths for data corruption.

TL;DR the adaptors don't follow USB bulk-attached storage protocol standards and are not fit for purpose. Get your money back, and/or use them in "one adaptor per running system" configurations if you're comfortable, but I wouldn't be confident in their ability to do anything other than perhaps handle boot duties.

Regarding the "professional" level of the NAS - while it is not a business use case, I imagine that the desire to keep your personal photos and media safe is fairly high. You can quite easily purchase a surplus desktop or even a "server" system with four or six hard drive bays for a small sum that will significantly make it more robust. This will depend on your country - but in North America I can fairly easily obtain a 4-bay 3.5" system such as a Dell PowerEdge T110 for about USD$50 with a low-end Xeon and 8GB of RAM. That makes a fine candidate for a small home system.

 

[sutusa]

I do not consider myself a storage admin... but I just had the same problem in my personal homelab as @Elixor, and I was able to figure it out. Let's just say that I bought one too many 4-bay drive enclosures from "back-alley manufacturers in Shenzhen". My USB3 enclosures were showing all 4 drives with the same serial number. Literally just a made-up serial like: DB123456789ABC.

The above was triggered issues in TrueNAS for me. The two issues I noticed were:

• The multipath issue that is referenced here in this thread at boot-time... when there is no multipathing in my setup.
• The front-end web GUI was not showing all of my drives during Pool creation... (even after fixing the multipath issue). I think the GUI still looks for unique serials, even though FreeBSD was seeing all of my drives via geom disk list.

In older versions of FreeNAS (pre 11.3), I was able to work around this issue via the web GUI somehow (don't remember how). But last night, I was seeing this issue in a more current version of TrueNAS (TrueNAS-12.0-U1.1) when I wanted to rebuild one of my pools... and I could not easily see the harddisks via the gui to build a new pool.

The general workaround was to create the disk partitions by hand using gpart and then create the zfs pool by hand using zpool create and referencing each drives gpt's rawuuid.

Code:

# For reference, my setup looks like this:
#   4-Bady Drive Enclosure:
#     - Disk1 (da1 in TrueNAS)
#     - Disk2 (da2 in TrueNAS)
#     - Disk3 (da3 in TrueNAS)
#     - Disk4 (da4 in TrueNAS)

# Remove the bogus multipaths:
gpart destroy da1
gpart destroy da2
gpart destroy da3
gpart destroy da4

# Create a GPT partition on da1
gpart create -s gpt da1

# Add a partition starting at block 128, use 2G for a 'freebsd-swap' partition
gpart add -b 128 -s 2G -t freebsd-swap da1

# Add a partition (starting at next available block) for a 'freebsd-zfs' partition.  This uses all available space.
gpart add -t freebsd-zfs da1

# Do this again 3 more times for the other 3 disks of the 4:
gpart create -s gpt da2
gpart add -b 128 -s 2G -t freebsd-swap da2
gpart add -t freebsd-zfs da2

gpart create -s gpt da3
gpart add -b 128 -s 2G -t freebsd-swap da3
gpart add -t freebsd-zfs da3

gpart create -s gpt da4
gpart add -b 128 -s 2G -t freebsd-swap da4
gpart add -t freebsd-zfs da4

# Save each drive's rawuuid for reference in zpool creation.
gpart list da1 | grep -i rawuuid | tail -1
gpart list da2 | grep -i rawuuid | tail -1
gpart list da3 | grep -i rawuuid | tail -1
gpart list da4 | grep -i rawuuid | tail -1

# I wanted a raidz2 encrypted pool named 'foobar'. Because of the encryption, I needed to
#  create (via a secure method of your choice) a private-hex key that is 64-characters
#  in length. (e.g: 0393db11ab82ab1e211c85d51047931b59f3b0cd8e1c9c926d8f0d49f0a524b2).
#  This is not my real key of course.
#
# This step is usually done for you by the web gui, which allows you to download a .json
#  file with this key.  I just made mine by hand like below.  Just reference your pool name
#  in the key/value pair and save the file for input later via the web gui.
#
# {
#     "foobar": "0393db11ab82ab1e211c85d51047931b59f3b0cd8e1c9c926d8f0d49f0a524b2"
# }
#

# Create your pool referencing the gpt rawuuids from previous commands.
#  During pool creation, you will be prompted for your private hex key.
zpool create \
  -O encryption=aes-256-gcm \
  -O keyformat=hex \
  foobar \
  raidz2 \
  gptid/f5504708-99b0-11eb-8860-005056875242 \
  gptid/324b1d73-99b1-11eb-8860-005056875242 \
  gptid/5ec29853-99b1-11eb-8860-005056875242 \
  gptid/66ab28e6-99b1-11eb-8860-005056875242

# You should know have a valid zfs pool:
zpool status foobar

# Until you export this pool and re-import via the web gui, you will not be able to manage/see this pool from the front-end gui.
zpool export foobar

# Now reimport via the web gui, you should be prompted to provide the .json key.

The above steps essentially worked around this issue for me. The multipath issue does not re-appear when the pool already exists during reboots.

With all that said, I think that @HoneyBadger is correct. The real fix is to not use cheap and crappy commodity parts and get a real server or bay that passes through the drive's serial number. This is just workaround stuff that should only be used in a homelab (and not at work) if you're stubborn like me.

Hope this helps.

 

[ChrisRJ]

I can only echo what @Patrick M. Hausen wrote: do not use this hardware. Parts that already create such problems before situations like a disk problem is in the game, cannot be trusted with anything. Unless this is an exercise in the category "Can I somehow make it work, sort-of?" what would I want to do with it. It is neither useful for putting data on there, nor for learning TrueNAS (because it is not a realistic scenario).