Review [Mini review] ROCK64 SATA cable

[tkaiser]

 

The above thing is a $10 accessory that can be ordered together with ROCK64 (and maybe other Pine Inc. devices like Pine64 or Pinebook?). It's an USB-to-SATA bridge (JMicron JMS578 based) to be used together with 2.5" SSD/HDD or 3.5" HDD. For the latter purpose it's equipped with a separate power jack suitable for the usual 12V 5.5/2.1mm power barrels (centre positive) you find PSUs with literally everywhere.

 

TL;DR: If you want to add storage to your ROCK64 order this cable too. It works great with both 2.5" and 3.5" disks and it's somewhat sad it's not available separately since it's a great storage companion for many other devices too.

 

Basics first:

• Mechanical quality of USB jack is excellent, Pine folks took care that the jack fits really tightly in USB receptacles so USB3 contact issues should not be an issue here (tested on ODROID-XU4 which is my worst device in this regard. The Pine adapter worked great and these pretty nice XU4 USB3 storage performance numbers were produced with Pine's adapter)
• The device is not really black but it's just a very dark but translucent plastic. If it's connected to an USB port and thereby powered a solid blue led is shining through. Disk activity is shown with a blinking red led in parallel. If you hate blinking leds like me turning the device 180° over is sufficient
• JMS578 as USB-to-SATA bridge is an excellent choice since amazingly fast, 'USB Attached SCSI' capable, same with 'SCSI / ATA translation' and even TRIM (though software support for this still missing in Linux)
• When combined with 2.5" disks the whole power consumption happens through the USB cable. Keep in mind that USB2 ports are rated for 500mA and USB3 ports for 900mA max. ROCK64 AFAIK allows 650mA on the USB2 ports and 950 mA on the USB3 ports. In other words: chances are great to run in underpowering problems when you connect 2.5" disks to the USB2 ports and run heavy loads on it (see below).
• 3.5" HDDs need not only 5V but also 12V. Usually the motor spinning the platters is on the 12V rail while internal electronics and the stepper motors to move around the head(s) are on the 5V rail. Please always keep in mind that Pine's SATA cable unlike any 'real' 3.5" HDD disk enclosure uses the separately provided 12V only to feed pins 13-15 on the SATA power connector. 5V consumption for the JMS578 and the disk's 5V rail has still to be provided by the device the SATA cable is connected to since coming from the USB power lines. On 'real' disk enclosures the 12V are internally also used to generate the 5V so an external disk is NOT powered in any way by the connected host. With this cable it's different!

 

Below is the standard SATA power connector pinout. 3.3V are usually not used, 12V are needed for 3.5" HDDs and 5V are always required. The JMS578 bridge chip needs some 5V juice too which is also taken from the connected host/board via USB power lines.

 

 

We already have a lot of performance numbers with fast SSDs connected to JMS578 (see https://forum.armbian.com/index.php?/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=34192 or there for example) so let's focus on real-world use cases this time: A large 3.5" HDD connected to a ROCK64 serving as a NAS or backup disk.

 

Let's start with some consumption numbers with an idle ROCK64. In the meantime I've 3 different ROCK64 generations on my desk (1st dev sample with 2GB and unusable USB3, 2nd gen dev sample with 4 GB and now a production board with 1 GB DRAM and a different Gigabit Ethernet PHY). Measurements done without PSU taken into account:

 

Pre-production board, 4GB, RTL8211E PHY:

• Idle, Fast Ethernet active, nothing connected: 1100mW
• Idle, GbE active, nothing connected: 1430mW 

 

Production board, 1GB, RTL8211F PHY:

• Idle, Fast Ethernet active, nothing connected: 1180mW
• Idle, GbE active, nothing connected: 1300mW
• Idle, GbE active, JMS578 connected: 1720mW
• Idle, GbE active, JMS578 with sleeping disk: 2850mW

With RTL8211E PHY the difference between GbE and Fast Ethernet was 330mW (on most GbE boards with 8211E it's exactly like this: ~350mW) and now with RTL8211F the difference is just 120mW (difference on ODROID-C2 which also uses 8211F is 230mW). When adding the JMS578 cable w/o connected disk consumption increases by 400mW. In this (rather useless) mode the JMS578 hides itself on the USB bus (lsusb output shows nothing -- interestingly on ODROID HC1 which also relies on JMS578 this is different) and obviously JMS578's USB and SATA PHYs are powered off. As soon as a disk is connected but sent to sleep JMS578 now consumes +1.5W and appears on the USB bus (now JMS578 has to power 2 highspeed PHYs: USB3 and SATA 3.0).

 

So with production ROCK64 boards minimal idle consumption is 1.2W (PSU's own consumption excluded). But as soon as we connect this cable with a disk behind idle consumption more than doubles (+1550mW) even if we send the disk to sleep. That's bad news for use cases that require a connected disk only running from time to time since now the JMS578 consumes more energy than the board itself.

 

Edit: I discovered recently that the HDD I was testing with has a rather high standby/sleep consumption so the +1550mW are not JMS578 alone but maybe even largely the Seagate Barracuda. See here for details but keep in mind that while on ODROID HC2 also a JMS578 is used it runs a different firmware which influences idle consumption behaviour a lot. More details on JMS578 firmwares: https://forum.armbian.com/topic/3317-orange-pi-zero-nas-expansion-board-with-sata-msata/?do=findComment&comment=43735

 

What are the options? With ROCK64 production boards we're fortunately able to toggle power provided to USB ports: https://forum.pine64.org/showthread.php?tid=5001

 

So the SATA cable connected to an USB2 port would allow to regain lowest idle consumption since we could unmount the disk when not needed, then send the disk to sleep using 'hdparm -y' (JMS578 fully supports 'SCSI / ATA translation so you can access every disk feature with hdparm or other low level tools!) and finally switch JMS578 off by cutting power on  the USB2 port. My personal use case is a ROCK64 with a huge 3.5" HDD to backup various macOS devices in the household. Backup performance is close to irrelevant and the only events needing top 'NAS performance' would be large restores or 'desaster recovery'. In other words: for normal backup operation once a day it would be sufficient to connect the disk to an USB2 port.  Nope, doesn't work any more, see below for details.

 

How does performance look like with a 7.2k 3.5" HDD (Seagate Barracuda from a few years ago):

 

The Barracuda is totally empty so able to achieve nice maximum sequential performance scores since testing only on the outer tracks (~170 MB/s):

USB3 / UAS (7.9W vs. 3.3W)                           random    random
     kB  reclen    write  rewrite    read    reread    read     write
 102400       4    11738    23147    25131    25087     1091      948
 102400      16    62218    77830    84257    84768     4246     4136
 102400     512   150052   148303   154342   163817    58563    97809
 102400    1024   148290   148324   156772   164963    85125   113412
 102400   16384   149840   149248   144297   151440   153146   133806
1024000   16384   167750   169544   172970   174205   160859   151406

When connected to an USB2 port performance drops a lot (maxing out at ~37MB/s):

USB2 / UAS (6.4W vs. 3.3W)                           random    random
     kB  reclen    write  rewrite    read    reread    read     write
 102400       4     7735     7849     6821     7925      998      916
 102400      16    17687    19040    20793    19430     3624     4096
 102400     512    33472    33662    33738    34329    26020    33683
 102400    1024    33836    34030    34855    35505    29941    28791
 102400   16384    34294    34373    35599    36694    36174    33714
1024000   16384    33600    34516    36576    36902    36372    34111

 

I tested backing up the same MacBook Air twice with ~70 GB data using Gigabit Ethernet (the usual Thunderbolt Ethernet adapter) and time difference was negligible comparing HDD connected to USB2 or USB3. When backing up through Wi-Fi there is no difference any more since Wi-Fi is the bottleneck. In other words: from a performance point of view for this use case connecting the SATA cable to an USB2 port and being able to totally cut power to both cable/JMS578 (+1.5W consumption) and a sleeping 3.5" disk (less than 0.1W consumption with almost all disks) is worth the efforts.

 

Once your MacBook gets stolen you simply disconnect the backup HDD from the USB2 and reattach it to an USB3 port and start the restore on your new device with +80 MB/s (Gigabit Ethernet now being the bottleneck) 

 

What about power requirements? ROCK64 only provides up to 650 mA on the USB2 ports! I tried to test this precisely with my usual 'monitoring PSU' approach. All I was getting were some nice kernel panics due to UNDERPOWERING. The Banana Pro I used to provide power (and measure consumption) simply does not provide enough current so Linux on ROCK64 started to fail in many funny ways once USB accesses happened.

 

So I had to revert on measuring with PSU included with a cheap powermeter (more realistic but not that precise).

 

When measuring only the 12V rail of my 3.5" Barracuda the disk consumed up to 18W when spinning up. In normal operation (either idle or with any workload) 12V consumption varied between 6W and 8W (12V only needed to spin the platters).

 

The 5V power requirements for JMS578 + 3.5" HDD disk were as follows:

• USB2: 6.4W vs. 3.3W (full load vs. idle). Numbers with 5V PSU included so we're talking about needed power provided on an USB2 port of approximately ~3W which fits perfectly in the power budget of ROCK64's USB2: 650mA * 5V == 3250mW
• USB3: 7.9W vs. 3.3W (full load vs. idle). Numbers again with 5V PSU included so we're talking about needed power provided on an USB3 port of approximately ~4W which fits perfectly in the power budget of ROCK64's USB3: 950mA * 5V == 4750mW

 

At least with my 3.5" HDD it worked pretty well to let it operate on both USB2 and USB3 ports when board powering was appropriate (with insufficient powering all weird sorts of issues popped up. My favourite was a kernel panic when issueing 'lsusb' after 30 seconds. Once I powered ROCK64 reliably all these 'software issues' were gone immediately -- again and again: insufficient powering is one of the most severe problem sources)

[tkaiser]

---

[infinity]

This is a great review! Quite helpful for me, as I have kind of the same usecase in my mind. The JMS578 power consumption is quite a showstopper. Do you happen to know whether asm1153e or asm1351 may be good alternatives? Looks like these chips do support UASP as well. Perhaps the power consumption would be lower on those? Or does anybody know whether other issues (like missing drivers; no hdparm support etc) might affect the suitability of the ASMedia chips as small USB3 NAS/backup-device usecase? 

[tkaiser]

2 hours ago, infinity said:

Do you happen to know whether asm1153e or asm1351 may be good alternatives?

 

No idea. I've one ASM1153E here but never measured consumption (only pretty unprecise and then I didn't notice differences to JMS567 or JMS578). Since the basic problem is always one USB3 SuperSpeed PHY and one SATA 3.0 PHY being active I also doubt that there are real power savings possible,

 

Though for JMicron SATA bridges we learned recently that there exists the possibility to update/modify the firmware so maybe there are some tweaks possible. While I'm currently in direct contact with JMicron (issue here) I don't want to ask these questions now since waiting for firmware fixes that provide full SAT compliance for JMS567/JMS578.

[infinity]

Thank you very much once again @tkaiser! I'm a bit disappointed by the high consumption and simply hoped that there are alternatives. Sure the additional SATA 3.0 PHY is present and need its power to function, thogh usually an SSD does consume less than 50mW in idle, where I expect an SATA PHY to be present as well on the SSD motherboard. Anyway, your hint about the possibility to upgrade firmware etc. is a real advantage in favour of JMS chips. 

 

Any pros and cons for JMS567 vs JMS578 ?

I assume I would do nothing wrong bying one like this: ORICO Adapter USB 3.0 zu SATA, USB 3.0 Konverter Kabel für SATA III 2.5 Zoll Festplatte HDD und SSD

(claiming to be JMS578 based)

 

By the way: Found this mini review, where the ASMedia chips seem to be way better performance wise: https://superuser.com/questions/1059492/usb3-to-sata-adapter-performance

 

EDIT

Apparently ASM1351 does a huge leap in random write performance compared to the others. Perhaps I should go for it and look how it is. I assume UASP is supported by recent/relevant Linux kernels for ASM1351? Would be interesting to see how it performs on a ROCK64 with current 4.4.77 ARMBian nightly.

[tkaiser]

26 minutes ago, infinity said:

 ORICO Adapter USB 3.0 zu SATA, USB 3.0 Konverter Kabel für SATA III 2.5 Zoll Festplatte HDD und SSD (claiming to be JMS578 based)

 

I bought two of them just to realize that they're based on crappy Norelsys chips (the reason why Armbian in the meantime does UAS blacklisting on its own -- the same happens on ayufan OS images for ROCK64 though there it's done differently). The JMS578 ORICO thingie looks different: http://www.orico.cc/goods.php?id=6355

 

31 minutes ago, infinity said:

ASMedia chips seem to be way better performance wise: https://superuser.com/questions/1059492/usb3-to-sata-adapter-performance

Please read through this carefully again. The guy has one JMS567 and there's something wrong with it (queue size limited to 14 for whatever reasons). When comparing ASM1153 and JMS567/JMS578 they perform both pretty identical (JMS578 should be able to support TRIM but AFAIK there's still software support missing in Linux)

[infinity]

Wow, thanks for both hints! Real crap, that they advertise it wrongly as JMS578 based. After doing some research I think I will give the Startech USB312SAT3CB a shot. It is based on a ASM1351 USB3.1 Gen2 controller, which (as some other little reviews show) apparently performs better than JMS578 and it has firmware support as well as Trim support added by a Startech firmware. It's a bit more expensive, but I think I can give it a try and see whether it is okay or not. Perhaps I'll make another order of the ROCK64, then I can directly add their JMS578 based USB3toSATA converter to have it as well.

[tkaiser]

50 minutes ago, infinity said:

ASM1351 USB3.1 Gen2 controller, which (as some other little reviews show) apparently performs better than JMS578

 

Well, with SuperSpeed I doubt there will be any real differences since 5 Gbps with 8b10b encoding means USB bottelenecking here with ~400MB/s maximum. And if the host is SuperSpeed Plus capable (10 Gbps with 128b132b encoding) then the SATA 3.0 controller on the other side of the chip will be the bottleneck (6 Gbps with 8b10b encoding --> ~480 MB/s max, no idea how/why benchmarks show up to 520 MB/s here). Though there might be differences wrt random IO but honestly: if I need high random IOPS then eliminating the USB bottleneck is a better idea.

 

These numbers here show that 'native SATA' provided by Marvell SoCs outperforms any USB3 solution easily especially wrt random IO (and I doubt ASM1351 will make a real difference here). BTW: same test with an EspressoBin shows only slightly lower numbers than the Clearfog from my link.

 

1 hour ago, infinity said:

Trim support

 

Is needed at both ends of the USB cable (and AFAIK it's still missing in Linux for USB)

 

[infinity]

Yep, I agree that it actually might make no noticable difference. Though I'd like to maximize the chances to have a good setup. Found this blog here: http://salutepc.altervista.org/ssd-on-usb-3-0-3-1-with-trim-support-windows-linux.html

 

He has almost the same setup as I have (or would like to have):

- Samsung 850 EVO

- StarTech.com USB312SAT3CB

- Windows and probably Ubuntu based Rock64 System

 

He also confirms working Trim and the numbers seem quite solid. So I think that startech thingy looks like a solid choice

[tkaiser]

6 hours ago, infinity said:

Found this blog here: http://salutepc.altervista.org/ssd-on-usb-3-0-3-1-with-trim-support-windows-linux.html -- He also confirms working Trim

 

Hmm... not really since this should happen at the driver layer. He uses a script describing 'We need a very modern hdparm, for its --fallocate and --trim-sector-ranges-stdin flags' which is interesting since I'll try TRIM with my JMS578 then soon  

[infinity]

5 hours ago, tkaiser said:

 

Hmm... not really since this should happen at the driver layer. He uses a script describing 'We need a very modern hdparm, for its --fallocate and --trim-sector-ranges-stdin flags' which is interesting since I'll try TRIM with my JMS578 then soon  

As far as I understood it, the script is responsible to get the Trim feature working on the OS. But the usb3.1 to SATA converter itself got the TRIM feature thanks to the firmware update. In my opinion it's the most important that the hardware itself (the cable) supports TRIM in the first place. The other thing is the OS, which is not the responsibility of the USB2SATA adaptor. I mean... the OS issue counts for all the cables and JMS578 as well as all the ASM1351. But if the cable won't ever support it, because the manufacturer does decide not to provide a respective firmware (with trim support enabled), then the best OS cannot change anything about this fact. So apparently JMS578 and ASM1351 are good choices. I will give the ASM1351 a shot, as the benchmarks are quite encouraging. Without this script, JMS578 wouldn't have working TRIM either, or not?

[tkaiser]

1 hour ago, infinity said:

Without this script, JMS578 wouldn't have working TRIM either, or not?

 

No idea. I tried the script on ODROID-XU4 and Banana Pi and it always fails in the same situation: 

hdparm --fallocate $whatever file

always returns with 'File too large' regardless of the size. Since the very same happens on the Banana Pi also when the SSD is connected via SATA maybe it's just a bug in hdparm v9.43 (that's the version Jessie and Stretch use, had no time to test with Ubuntu yet)

[neek0la]

Hi tkaiser

 

These cables will suit my projet perfectly.

 

I want to have a 2 x 3.5"Hard drives connected to a XU4 using these cables. How many amps would i need to do the lot with only 1 PSU?

Obviously will not to step down to 5V for the XU4.

[Ex3c]

Hi,

i have seen some interest in the ASM1351 Sata to USB3.1 Gen2 controller, and as i have a USB 3.1 case with this controller i did some power consumption tests.

In this case a HGST Travelstar 5K1000 1TB 2,5" HDD is mounted.

Test where done with a headless RaspberryPi 3 (only power supply and the tested USB device connected),  a KD302 wall power meter (measuring the complete power including the power supply) and a Drok USB 3.0 power meter (measuring only the power consumed by the USB device).

"delta KD302" means the difference between headless Raspberry and the Raspberry with this USB device.

USB3_BRDIGE is the empty case, without the HDD; only the  bridge PCB

USB3_HDD  is the complete case, bridge PCB + HDD

 

                                                   KD302       |   delta KD302   |    Drok

---------------------------------------------------------------------------------

Power Supply idle                     :  0.2W                                
RaspPi3                                     :  1.8W                              

RaspPi3 + USB3_BRDIGE           :  2.35W      |    0.55W           |    0.34W
RaspPi3 + USB3_HDD                :  2.75W      |    0.95W           |    0.67W

 

The differences between the delta of the KD302 and the values of the Drok result probably mainly from the effeciency of the power supply (~70% ?).

Also some extra power consumption of the Raspberry when a USB device is connected or the precision of the power meter could have a influence.

 

So it seems that the ASM1351 have a lower idle power consumption compared the JMS578 and maybe also show better performance.

[q-bert]

Great review! I have a similar setup. How can I cut power to the USB 2 port and turn it back on automatically (e.g.  backup job or other software wants to access the hdd)? 

Using hdparm I am able to define a period after which the drive should spin down. Where do I go from here and how can I turn the drive back on?

[tkaiser]

6 minutes ago, q-bert said:

How can I cut power to the USB 2 port and turn it back on automatically (e.g.  backup job or other software wants to access the hdd)?

 

You can't with current Rock64 releases since ayufan defined the GPIO pin in device-tree and so it's not accessible any more from userspace. With his older images (0.5.1 and before) the following was possible:

GPIO=2
USB_Power_Node=/sys/class/gpio/gpio${GPIO}
[ -d ${USB_Power_Node} ] || echo ${GPIO} >/sys/class/gpio/export
echo out >${USB_Power_Node}/direction
hdparm -y /dev/sda
sleep 2
echo 1 > ${USB_Power_Node}/value

BTW: what I didn't know back then is that this GPIO controls power to all USB ports (USB3 included) but the way the pin currently is defined it's not possible to toggle power to the USB ports any more.

[q-bert]

Bummer, thanks for the update. Do you know if there are any chips which consume less energy than JMS578? USB 2 is fast enough for my use case.

[tkaiser]

27 minutes ago, q-bert said:

Do you know if there are any chips which consume less energy than JMS578?

 

Nope. The problem is that such a SATA controller (regardless which highspeed bus between CPU and the controller is used... read as: this also applies to PCIe SATA controllers) usually has 2 high-speed PHYs active:

• USB3 or PCIe PHY to host
• SATA PHY to HDD/SSD

Each PHY consumes usually up to half a W so we can easily do the math. Sometimes it's possible to get slight consumption savings by slowing down interfaces (in your case switching from SuperSpeed to Hi-Speed or with SATA controllers from 6Gbps to 3 or just 1.5) but it's not always possible to control the behaviour (at least with USB attached SATA, with PCIe controllers it's usually just telling the kernel driver what to do)

 

Edit: Just found it. Copy&paste from my report to Cloudmedia/Pine folks about the above issue with GPIO 2 not able to toggle from userspace any more: 'Between hdparm -y and setting the sysfs node to 1 there's a consumption difference of 1.2W in my setup (and the SSD used has a standby consumption of 0.4W so the remaining 800mW are in my case the ASM1153 bridge inside the external USB enclosure). 1.2W less in idle (or 1.8W vs 3.0W) can be considered a huge difference :)'

[tkaiser]

On 8.1.2018 at 8:25 PM, Ex3c said:

So it seems that the ASM1351 have a lower idle power consumption compared the JMS578

 

Not really since I tested in the beginning with a Seagate Barracuda that shows an insanely high standby/sleep consumption. I updated the 1st post with this...

[q-bert]

34 minutes ago, tkaiser said:

 

Nope. The problem is that such a SATA controller (regardless which highspeed bus between CPU and the controller is used... read as: this also applies to PCIe SATA controllers) usually has 2 high-speed PHYs active:

• USB3 or PCIe PHY to host
• SATA PHY to HDD/SSD

Each PHY consumes usually up to half a W so we can easily do the math. Sometimes it's possible to get slight consumption savings by slowing down interfaces (in your case switching from SuperSpeed to Hi-Speed or with SATA controllers from 6Gbps to 3 or just 1.5) but it's not always possible to control the behaviour (at least with USB attached SATA, with PCIe controllers it's usually just telling the kernel driver what to do)

 

Edit: Just found it. Copy&paste from my report to Cloudmedia/Pine folks about the above issue with GPIO 2 not able to toggle from userspace any more: 'Between hdparm -y and setting the sysfs node to 1 there's a consumption difference of 1.2W in my setup (and the SSD used has a standby consumption of 0.4W so the remaining 800mW are in my case the ASM1153 bridge inside the external USB enclosure). 1.2W less in idle (or 1.8W vs 3.0W) can be considered a huge difference :)'

 

Thank you!

[berbec]

On 9/6/2017 at 4:20 PM, tkaiser said:

TL;DR: If you want to add storage to your ROCK64 order this cable too. It works great with both 2.5" and 3.5" disks and it's somewhat sad it's not available separately since it's a great storage companion for many other devices too.

 

 

As of today, you can order this by itself: Pine64 Shop

 

It really seems like a great deal! Thanks for the in-depth review. I've paid more for devices that don't support UASP or external power for 3.5" drives. I believe I will pick one up for my go-bag.

[Attila Vangel]

On 9/6/2017 at 10:20 PM, tkaiser said:

The 5V power requirements for JMS578 + 3.5" HDD disk were as follows:

• USB2: 6.4W vs. 3.3W (full load vs. idle). Numbers with 5V PSU included so we're talking about needed power provided on an USB2 port of approximately ~3W which fits perfectly in the power budget of ROCK64's USB2: 650mA * 5V == 3250mW
• USB3: 7.9W vs. 3.3W (full load vs. idle). Numbers again with 5V PSU included so we're talking about needed power provided on an USB3 port of approximately ~4W which fits perfectly in the power budget of ROCK64's USB3: 950mA * 5V == 4750mW

Hi, I found this thread somehow. I still do not understand how this could work, because even the idle drive power consumption is maxing out the power budget in the USB2 case, but the full load highly exceeds the power budgets for both USB2 and USB3 cases.

What I really want is to connect 2 pieces of 1500GB 3.5" HDDs (Samsung HD154UI, bought them long time ago, but were powered on seldom, so still in good shape), and have some kind of data mirroring (like sofware RAID 1 or periodic rsync). I don't mind if the speed is capped by the USB2 speed limit.

What kind of accessory / USB-to-SATA thingy to buy for this purpose to avoid underpowering issues even with 2 HDDs connected? How to not draw power from the board if that helps? Can I have both drives connected to the USB3 port with some gadget? Even though the performance of USB3 will be divided, this may still be better than the bottleneck of USB2, I guess. What extra part to buy in this case?
Thanks in advance!

[S_R]

Hey, I've got a rock64, USB case with a JMS578 and a Samsung 860 evo 1Tb (ext4) in it which I'm trying to trim.

I've tried it with fstrim and the wiper.sh script from here, both without success. The JMS578 is running v173.01.00.01 from odroid.

After verifying that trim really doesn't work with a method like this    , I'm now kinda worried about my drive health long term as even garbage collection doesn't seem to help here (because of ext4?). As people are successfully trimming with the same setup but with a 850 evo instead, I guess the problem lies here.

 

Now my question, how can I fix this and is trimming really that important? Did anybody get trim working on a 860 evo over usb with a different cabel/case maybe?

Unplugging the drive and hooking it up to a linux machine with sata from time to time should work as the last option should work I guess.

Thanks in advance

[S_R]

I bricked my JSM578 with the v255.1.0.1 beta firmware, so I got a new enclosure from Orico (2139C3) http://www.orico.cc/goods.php?id=6352 with a VL716 chipset.

After adding a udev rule as described here TRIM works perfectly fine now.