Any known external HD enclosures that work w/Rockstor?

[jrmclaugh (James)]

When searching the forums, it seems the major roadblock for external multi-bay drive enclosures working with Rockstor is whether or not they report drive serial numbers correctly. I see that there have been several workarounds implemented for specific cases here:

rockstor/rockstor-core/blob/f10beb9813001e8d2b275fd56b2bd6c21da638e6/src/rockstor/system/osi.py#L83

Has anyone successfully run 4+ drive enclosures (USB 3.0 or firewire) without requiring the workarounds?
Do the ones listed in that code at least work ok enough with Rockstor?

I understand USB in general is a no-no, but I bought some WD Red’s thinking I could just toss them in one of those enclosures to run with my laptop-based server and I’d prefer not to have to buy an entirely new (server) computer just to use them.

Thanks!

[phillxnet (Philip Guyton)]

@jrmclaugh Welcome to the Rockstor community.
I can jump in on this one:
Re:

I see that there have been several workarounds implemented for specific cases here:

These are more refusals / flags to avoid rather than work arounds. We just can’t use this type of device so in this last bit of code you quoted (from 4.1.0-0 indicentally) we have centralised this refusal/flagging mechanism to make it easier to manage. Previously we had some front-end code and some back-end code which both did pretty much the same thing but for different subsets of duff serial numbers. So we now have a central duff/unusable serial number list to more easily keep on top of these as they are reported.

Do the ones listed in that code at least work ok enough with Rockstor?

No they can’t work in any way actually, the link in that comment block point to why. We just have to flag them as not being appropriate for Rockstor. It’s a shame they did this and clearly wrong from our use case.

Has anyone successfully run 4+ drive enclosures (USB 3.0 or firewire)

Great question actually and I hope we get some responses here.

You may want to extend that to ESATA as that’s a good interface for such things too, if a little slow as when I last looked it was SATA2 only. But at least it’s not USB which has reliability issues.

I’ve not tested any myself yet but it would be good to know of ones that do so things properly, i.e. present drives as they are, not mutated and munged together from a unique id point of view. Sill thing to do actually but oh well. I expect they had a different use case/OS in mind when they made this decision.

I understand USB in general is a no-no, but I bought some WD Red’s thinking I could just toss them in one of those enclosures to run with my laptop-based server and I’d prefer not to have to buy an entirely new (server) computer just to use them.

Exactly. Flexibility in depolyment is nice. So if anyone does have any external enclosures it would be great to have some feedback on this question. In both directions actually as we can help others avoid duff ones by adding them to this now centralised list if they turn our to return identical serials for all their hosted drives.

For those wandering what this is all about. Some external drive enclosures obfuscate (read replace) all their drive serials with the same serial they deem to be of use. It isn’t. And so Rockstor can’t then track drives. Drives each have unique serials for this very reason. It is wrong to change / obfuscate / undo this. Bad enclosures.

If we do get a list of know working external enclosures we should make a specialised doc entry for them as it’s something that has come up a few times and it’s a major convenience in many non critical installs. It has it’s drawbacks but we are pragmatic here and some of these enclosures are really nice and would be handy for home deployments and the like where the technical limitations and increased points of failure are by-the-by.

Hope that helps and thanks again for asking this question. Lets hope we get some feedback on this one.

[jrmclaugh (James)]

Thanks for the thorough reply @phillxnet!

That makes more sense it’s a centralized list of known-bad ones based on the comments. Too bad, but at least I know specifically which to avoid!

I agree the behavior of these is bad, and probably doesn’t bode well for their overall quality aside from the serial number obfuscation. I know some of those enclosures offer USB and ESATA, I wonder if the ESATA on them also obfuscates, or it’s just the USB interface.

I appreciate the flexibility here and its part of why I’m wanting to use it over other more…strict…NAS server OS’s. Can’t seem to even discuss the possibility to understand what the risks really are.

Hopefully someone chimes in with functional ones! I may end up pulling the trigger on an unknown one if I know I can return it in the event it doesn’t work. I’ll have a look at ESATA as well, but I believe I would need another $100-ish adapter to get it to work with the existing laptop server. Maybe this can just be my excuse to upgrade my main computer and use the existing one as the server (with enough space/sata ports to not be an issue).

[phillxnet (Philip Guyton)]

@jrmclaugh Re:

@jrmclaugh

and probably doesn’t bode well for their overall quality aside from the serial number obfuscation.

Agreed.

@jrmclaugh

I know some of those enclosures offer USB and ESATA, I wonder if the ESATA on them also obfuscates, or it’s just the USB interface.

Yes, I’ve wondered this myself. I suspect it still does. We haven’t had any reports from anyone who owns one who could tell either way. But as you see from the list to date and the issues associated with the progression of this list. A goodly number of them are based on the JMS567 controller chip. I.e. the issue I did the centralisation against was our third report of such an enclosure:

https://github.com/rockstor/rockstor-core/issues/2330

Hence the clean-up to more easily (and more sanely) accommodate similar reports.

You might be able to ask a question of the manufacture or re-seller. But I doubt you will get a proper answer to this capability. We are actually pretty strick on this serial front unfortunately as we have it as a core element of our design.

One thing I wondered out-aloud here on the forum in one of the reports was if the drives were awarded udev identifiable ‘ports’ or the like according to their position in the enclosure. But apparently not. If that was the case we may be able to given them a serial from there. Still not drive tracking but bay tracking. However if folks knew that then it’s a rubbish but doable work around. However that one didn’t pan out.

Let us know how you get on. And hopefully we will get some feedback from others with such hardware.

Cheers.

[phillxnet (Philip Guyton)]

@jrmclaugh Re:

@phillxnet

One thing I wondered out-aloud here on the forum in one of the reports was if the drives were awarded udev identifiable ‘ports’ or the like according to their position in the enclosure.

Here is that ‘wondering’

USB Disks with no Serials

@Brett_Abela Thanks for the info. From: We see each of the 3 drives in the Orico enclosure has a by-id name, which is part of the problem sorted (no serial devices get no by-id name at all), but what we now need to know is if those names are assigned on a first come first served basis, which may change from one boot to the next, or as I am hoping, on a bay/enclosure-slot basis. Can you see if you can establish this? Ie you have 2 different models of drive there and given the enclosure rather u…

and:

@phillxnet

But apparently not.

was from @outicnz discouraging report on that front:

@outicnz

To answer your question on whether the “0:0” or “0:1” is assigned by the bay of the drive. Sadly not. The last digit sequentially increases for each drive detected regardless of the bay that it is located in.

Just for context given your interest in this area currently.

[jrmclaugh (James)]

Thank you for compiling all the relevant discussions on it! I should have included those on my original post.

Also just replying to clarify that post, since I can’t seem to edit it:
Thunderbolt 2 or 3 was what I meant, not firewire. Perhaps is a more reliable interface than USB 3.x? I’m researching independently for that, as well.

[ogremustcrush (Mike)]

Terra-Master D4-300 or other enclosures that use ASM1074(hub)/ASM1153(sata bridge) chipset such as Syba SY-ENC50119. Unlike most multi-bay enclosures that have an internal sata port multiplier (and typically use Jmicron chipset that cannot pass through serial number in that configuration) the ASM1074/ASM1153 appears as a USB 3.0 hub with multiple sata bridges attached to it (which is exactly what it is, ASM1074 can be used as a USB hub without any hard drives at all.) Interestingly at least on the Terra-Master the usb-sata bridges identify to the usb controller as 1.5TB Toshiba drives with unique serial numbers per bay, but the hdparm -I and udevadm -info are correct for each drive and use the drive’s serial number rather than the bridge’s.

 /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 2: Dev 37, If 0, Class=Hub, Driver=hub/4p, 5000M
        ID 174c:3074 ASMedia Technology Inc. ASM1074 SuperSpeed hub
        |__ Port 1: Dev 38, If 0, Class=Mass Storage, Driver=uas, 5000M
            ID 0480:a006 Toshiba America Inc External Disk 1.5TB
        |__ Port 2: Dev 40, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
            ID 0480:a006 Toshiba America Inc External Disk 1.5TB
        |__ Port 3: Dev 41, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
            ID 0480:a006 Toshiba America Inc External Disk 1.5TB
        |__ Port 4: Dev 39, If 0, Class=Mass Storage, Driver=uas, 5000M
            ID 0480:a006 Toshiba America Inc External Disk 1.5TB 

Bus 002 Device 038: ID 0480:a006 Toshiba America Inc External Disk 1.5TB
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.00
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         9
  idVendor           0x0480 Toshiba America Inc
  idProduct          0xa006 External Disk 1.5TB
  bcdDevice            1.00
  iManufacturer           2 TDAS
  iProduct                3 TerraMaster
  iSerial                 1 20220817607E
  bNumConfigurations      1

P: /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2.4/2-2.4:1.0/host6/target6:0:0/6:0:0:0/block/sdc
N: sdc
L: 0
S: disk/by-path/pci-0000:00:14.0-usb-0:2.4:1.0-scsi-0:0:0:0
S: disk/by-id/wwn-0x5000c500e3ab40c0
S: disk/by-id/ata-ST8000DM004-2CX188_ZR12YT1N
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2.4/2-2.4:1.0/host6/target6:0:0/6:0:0:0/block/sdc
E: DEVNAME=/dev/sdc
E: DEVTYPE=disk
E: DISKSEQ=57
E: MAJOR=8
E: MINOR=32
E: SUBSYSTEM=block
E: USEC_INITIALIZED=653913118648
E: ID_ATA=1
E: ID_TYPE=disk
E: ID_BUS=ata
E: ID_MODEL=ST8000DM004-2CX188
E: ID_MODEL_ENC=ST8000DM004-2CX188\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
E: ID_REVISION=0001
E: ID_SERIAL=ST8000DM004-2CX188_ZR12YT1N
E: ID_SERIAL_SHORT=ZR12YT1N
E: ID_ATA_WRITE_CACHE=1
E: ID_ATA_WRITE_CACHE_ENABLED=1
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=66518
E: ID_ATA_FEATURE_SET_SECURITY_ENHANCED_ERASE_UNIT_MIN=66518
E: ID_ATA_FEATURE_SET_SMART=1
E: ID_ATA_FEATURE_SET_SMART_ENABLED=1
E: ID_ATA_FEATURE_SET_PUIS=1
E: ID_ATA_FEATURE_SET_PUIS_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=5425
E: ID_WWN=0x5000c500e3ab40c0
E: ID_WWN_WITH_EXTENSION=0x5000c500e3ab40c0
E: ID_PATH=pci-0000:00:14.0-usb-0:2.4:1.0-scsi-0:0:0:0
E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_2_4_1_0-scsi-0_0_0_0
E: DEVLINKS=/dev/disk/by-path/pci-0000:00:14.0-usb-0:2.4:1.0-scsi-0:0:0:0 /dev/disk/by-id/wwn-0x5000c500e3ab40c0 /dev/disk/by-id/ata-ST8000DM004-2CX188_ZR12YT1N
E: TAGS=:systemd:
E: CURRENT_TAGS=:systemd:

Note that if like me you are passing through the drive through proxmox/kvm in scsiblock=1 mode to a Rockstor VM, you will need to update the udev rules for Rockstor as otherwise it will only read the udev attributes from the UAS bridge, rather than those from the disk itself and the bridge attributes don’t seem to pass through properly by default and you’ll have the same issues with drives sharing the same seral/wwn as with a enclosure that messes up the SN info. On the host this doesn’t happen as udev knows the drive is connected via USB, but the passthrough makes it look like a native scsi disk. I just copied /usr/lib/udev/rules.d/60-persistent-storage.rules to /etc/udev/rules.d/ and added to the ATA section the below line so any vendor==TDAS* devices are identified using ata_id instead of scsi_id:

KERNEL=="sd*[!0-9]|sr*", ENV{ID_SERIAL}!="?*", SUBSYSTEMS=="scsi", ATTRS{vendor}=="TDAS*", IMPORT{program}="ata_id --export $devnode"

Of course you’ll want to add -d sat as the smartctl option for SMART to work (probably not necessary running bare metal though.)

Hope this helps someone, I had originally tried re-flashing one of the Jmicron based enclosures but ultimately gave up on that as a dead end. The D4-300 is a pretty nice box too, nice toolless drive caddies and what appears to be pretty good cooling. I think they have a 5 bay using the same chipset, but it has some RAID stuff built that might cause issues, not sure how that is implemented with the hub/bridge architecture. Mind I just barely got this working, don’t know about reliability/performance in this configuration yet, so try this at your own risk.