I’ve ordered the D5-300 model and planned to initially use it with 2 drives in raid mirror. I had some uncertainty if I can use it on linux; officially it’s not supporting linux, only Windows and Mac, however the seller here on Amazon replied to two user questions with a yes, so I went ahead and ordered. Well… it was not a problem free to make it work (on my system, YMMV), but managed to reach a state where I can use it with some remaining issues.
So when I first plugged in the unit with same drives (at my workplace right after receiving it), only the first drive was accessible. I tried on 3 computers, but all were running somewhat old-ish installs, I believe the most recent had kernel 3.2.0 running. Arriving home I tried it my most up-to-date system: my Raspberry Pi 3 running Arch linux with kernel 4.4.1, but still it did not work. As a next attempt I’ve updated my debian on my desktop to kernel 3.16.something and finally signs appeared that this might going to work. So I finally plugged in to the box where I planned to use it (firewall/NAS) and compiled kernel 3.18.35, with which the drives did show up, I could read the raw (empty) drives at decent speeds (sorry, don’t remember the exact figures), but when tried formatting and generally writing to any of the attached drives things have fallen apart. The kernel by default used the more modern USB UAS driver, which were logging some error messages while trying to write to the unit. After some research I’ve discovered that this enclosure uses the infamous JMicron JMS567 controller (USB ID: 152d:0567), which is known to have problems on linux showing diverse range of symptoms depending on actual unit firmware and kernel versions. After I’ve disallowed the usage of the UAS driver (though USB quirks) I was able to write to the unit reliably (using the old standard USB Mass Storage driver).
So the unit was working at this point and I could create my (software) RAID volume on top, format it and start copying stuff over, however I soon discovered 4 caveats, which I couldn’t fix sadly ever since:
-
Speed:
While with the UAS driver I got speeds clearly showing USB3 is used, with the Mass Storage driver I am stuck with a total maximum speed of around 60Mbyte/s; even though it’s connected to USB3, I can’t utilize it. This is expected mainly to be the fault of the firmware in the unit and that the kernel developers weren’t able to work around all the issues encountered.
-
SMART monitoring:
For some strange reason I can not query the SMART state of the first drive in the enclosure. When I say first driver, it’s not the left-most drive I am talking about, it is not the one plugged in as first, it’s the one which gets assigned the ‘lowest’ alphabet character in it’s device name (sde in my computer). Confused? Read the next caveat below.
-
Drive ordering and device name assignment:
One would might expect that drives plugged in will come in a certain order be it by slots left to right, or whatever. Well with this unit I was not able to discover the rules around this. As mentioned above I can’t read the SMART state of the ‘first’ drive; when I discovered this I had two 3TB WD Red drives in the unit. I tried all five slots, I tried swapping the two drives around, none of this helped any. My final workaround was that I inserted an older 750GB drive, which I am not going to use much (certainly not store anything important on it) as I can’t monitor it’s health. Now the interesting bit here is that the 750GB drive was inserted last, but after power cycling the enclosure it became the ‘first’ drive and kept that position/‘title’ even when I was juggling around the drives in the bays seeing if I can confuse the unit (it ended in up in slot 3). Since then I filled up the remaining slots, so I have one un-monitored 750GB and 4x 3TB drives, which respond to SMART queries fine. So once the enclosure decided on the ‘first’ drive things stay put… unless… read on!
-
Hot swapping and power management:
Well the enclosure officially supports hot swapping and also kinda does in practice, whoever during my experiments trying to find out what makes a drive be the ‘first’ drive I observed the following: if I pull out the ‘first’ drive with the enclosure off, then after turning on hot-plug it, the drive will be added at the end on the device list (as expected); power cycling the enclosure ‘moves’ back this drive to be the ‘first’ (which as also acceptable), whoever here is a dangerous issue:
!!! If you ever hot-plug a drive and the firmware wishes to position it to somewhere else AND you allow the enclosure to go to sleep (power saving mode), after re-engaging with the enclosure you will find you drives ‘re-positioned’, but your device names stay untouched resulting in potential crash, FS corruption and data loss !!!
Let me try this through and example: you turn on the enclosure with two drives initially, let’s call them A and B. The linux kernel assign device name sde and sdf. Then you hot-plug a third drive C (let’s say this is the favorable ‘first’ drive for the enclosure), kernel assigns sdg to this. At this point all working and happy. Then you go out to your kitchen do a coffee and come back 5 mins later to find the enclosure gone to sleep (drive LEDs off). As soon as you start using one of the devices the enclosure wakes up, spins up the drives, REORDER them, but doesn’t let the kernel know. Suddenly you sde means drive C, sdf is A and sdg is B!
My workaround is: 1, no hot-plugging - well with a raid array I never planned to do so anyways. 2, I wrote a BASH 5 liner to keep the driver ‘entertained’ from cron all time (reading a random sector with dd) to avoid the enclosure going into sleep ever again. This second one is not strictly needed for avoiding drives getting mixed, it is only to avoid them getting stopped and then getting started back up again and again all the time.
I have to once more stress this: these issues are mainly attributed to the unit’s firmware and a Linux kernel version, it might behave completely differently on your, heck, it might work problem-free for you. I am just writing about my findings here in hope that it might help someone understanding what’s happening with his/her unit and might help to work around some issues.