M.2 SSD enclosure presenting SSD as HDD

[ssdnvv]

Hi,

I use my mSATA-slot for hosting the boot-drive (which is correctly recognized as SSD), slot 2 for WiFi and slot 3 for LTE.
To add storage for write-friendly software, I tried to add an NVME drive (WD Red SN700 1TB) via a no-name SSD enclosure (actually presenting itself as Realtek RTL9210B-CG) and expected to get hit by this bug, but found out, the enclosure is presenting the drive as hdd:

root@turris:~# lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda            8:0    0 931.5G  0 disk
mtdblock0     31:0    0     1M  0 disk
mtdblock1     31:1    0     7M  0 disk
mmcblk0      179:0    0   7.3G  0 disk
└─mmcblk0p1  179:1    0   7.3G  0 part /
mmcblk0boot0 179:8    0     4M  1 disk
mmcblk0boot1 179:16   0     4M  1 disk
root@turris:~# cat /sys/block/sda/queue/rotational
1
root@turris:~# lsblk --discard
NAME         DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                 0        0B       0B         0
root@turris:~# mount | grep sda
/dev/sda on /srv type btrfs (rw,noatime,space_cache=v2,subvolid=256,subvol=/@)

If I am correctly informed, it is crucial to get it detected as SSD, otherwise the device would wear out much faster, correct?
Is it dependend on the enclosure (/chipset) whether the SSD will be detected correctly or is this something that happens to all external devices (the same happened to me for a mSATA-drive, that was correctly detected as SSD when put into TO mSATA-slot or external mSATA-USB3-enclosure)?

(I did not choose this very drive for its NVME-speeds, but for the very low power consumption - the router is maintained by solar energy with only a small battery - and maximum drive writes compared to disk space so durability).

[Ignatz]

Hi ssdnvv,

@ssdnvv

If I am correctly informed, it is crucial to get it detected as SSD, otherwise the device would wear out much faster, correct?

Not entirely correct, the SSD takes care of wear leveling on its own. However, it can use the assistance of the operating system because:

It will eventually get slower, because if the operating system does not see an SSD, it won’t send any TRIM commands to have the SSD discard data that is not needed anymore. Therefore it will run out of unused blocks and need increasingly more time to locate some when new data is to be stored.

Is it dependend on the enclosure (/chipset) whether the SSD will be detected correctly or is this something that happens to all external devices

Your enclosure is to blame. My Omnia contains a mSATA drive and recognizes it as SSD.

I see two possibilities:

• Get rid of the adapter entirely by buying the kind of SSD your device has a slot for (my recommendation).
• Run TRIM manually or via script – that is, if your enclosure supports that. To check this, mount your SSD and run fstrim -v <mount point> on it. If it returns something like /srv: 2.2 GiB (2387677184 bytes) trimmed, create a cronjob for fstrim (maybe once a week).

Cheers,
Ignatz

[ssdnvv]

@Ignatz

Your enclosure is to blame. My Omnia contains a mSATA drive and recognizes it as SSD.

I see two possibilities:

• Get rid of the adapter entirely by buying the kind of SSD your device has a slot for (my recommendation).

I am sure my enclosure is to blame - that is what I meant when writing

@ssdnvv

Does it depend on the enclosure (/chipset) whether the SSD will be detected correctly or is this something that happens to all external devices (the same happened to me for a mSATA-drive, that was correctly detected as SSD when put into TO mSATA-slot or external mSATA-USB3-enclosure)?

I added missing information to the OP - my mSATA-slot contains a SSD which is used as boot-device. As I will constantly write data to the drive, that hosts my /srv (e.g. by using surveillance-cameras), I need to separate this device from the one used for booting/OS.
So in this case the mSATA-slot is no solution - and neither is a mPCIe → M.2 adapter used in one of the other slots, as I run a WiFi-card in slot 2 and a LTE-card in slot 3.
I therefore indeed need an external SSD-enclosure.
→ Is it possible to run SSDs in external enclosures, that will be presented to the OS as SSDs?

Edit: I ordered some more enclosures for testing. Seems the RTL9210B is advertised to offer UASP for my enclosure, but UASP+TRIM for other enclosures offering the same chipset. So maybe it is a bad implementation in my case. I will follow up on this as soon as the alternatives arrive.

[Ignatz]

@ssdnvv

I added missing information to the OP - my mSATA-slot contains a SSD which is used as boot-device. As I will constantly write data to the drive, that hosts my /srv (e.g. by using surveillance-cameras), I need to separate this device from the one used for booting/OS.

I see, I totally misunderstood you. Thanks for clarifying.

So in this case the mSATA-slot is no solution - and neither is a mPCIe → M.2 adapter used in one of the other slots, as I run a WiFi-card in slot 2 and a LTE-card in slot 3.
I therefore indeed need an external SSD-enclosure.
→ Is it possible to run SSDs in external enclosures, that will be presented to the OS as SSDs?

Linux does not care about whether a drive is inside the computer box or not, it’s the connector that matters. Since you asked, I got curious and hooked up my own external HDD, now ReForis looks like this:

[quoŧe]
Edit: I ordered some more exclosures for testing. […] I will follow up on this as soon as the alternatives arrive.
[/quote]

OK, I’ll wait.

Cheers.
Ignatz

[ssdnvv]

Next tries:

• Ugreen enclosure:

root@turris:~# lsusb
Bus 003 Device 003: ID 152d:0583 Ugreen Ugreen Storage Device
root@turris:~# lsblk --discard
NAME         DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                 0        0B       0B         0

so still the same problem, even though with this enclosure chipset at least the storage device itself is recognized:

• noname portable m.2 SSD-enclosure with ID SHL-R320:

root@turris:~# lsusb
Bus 003 Device 003: ID 0bda:9210 Realtek RTL9210
root@turris:~# lsblk --discard
NAME         DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                 0        0B       0B         0

this time even stating it holds an NVME-device…

• another Ugreen device with

root@turris:~# lsusb
Bus 002Device 002: 0bda:9210 Ugreen Ugreen Storage Device
root@turris:~# lsblk --discard
NAME         DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                 0        0B       0B         0

shows the same behavior as well as 3 other devices.

After digging a little bit deeper: TRIM is not out of the box supported in linux for all external devices (Enabling TRIM on an external SSD on a Raspberry Pi | Jeff Geerling). Support needs to be activated (if the enclosure’s chipset actually supports it - if not, damage can be done to enclosure/storage device).
To check if enclosures firmware supports TRIM, sg3-utils need to be installed but are not available for Turris even though they are for vanilla OpenWrt.

Plugable wrote a good howto for their device: https://kb.plugable.com/data-storage/trim-an-ssd-in-linux. There they state for the USB-C NVME-enclosure to enable TRIM by issuing

echo 'ACTION=="add|change", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="9210", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"' | sudo tee --append /etc/udev/rules.d/10-uas-discard.rules

As can be seen above most of the devices tested that far have the very same vendor / chipset, so there is a good chance this will work for them as well. But as OpenWrt and thus TurrisOS uses hotplug I need to figure out how to run that command on OpenWrt first

(I’d buy the Plugable enclosure right away, but it is only sold in JP/US and therefore costs >45EUR in europe…)

[nielsson4711]

If anyone else is searching for documented adapters and enclosures with support, try “DELOCK”. They are located in GER. I used to some of their USB-storage adapters with separate power supply, which is of value for external RasPi storage.