Recent Profile Visitors

As I rsync'd data around between the drives (all formatted with BTRFS), while doing no other disk operations to speak of, I would at first get 40MB/sec (shown with iotop), then after about 10 seconds, it would simmer down to 20MB/sec and stay there. So you can expect a solid 20MB/sec through those USB 2.0 cables (and the USB 3.0 cables were never any faster, even when no "UAS inflight" errors were getting generated), with quick initial surges of 40ish MB/sec. These speeds (when doing just one data transfer at a time) held true wether or not you wrote to SATA or a USB disk, and wether or not you used a spinning 3.5" drive, or an SSD.
So in conclusion, IMHO, this rig was born to run OpenMediaVault (in a small office of a few people, where it's usually/often the case that only one user at a time is hitting this server), but not Nextcloud! And those users should probably use Filezilla to transfer files (not Windows Explorer, ie. SMB3), if they are transferring any more than about 300MB (at which time I say it's worth one's time to spend the 30 seconds or so starting Filezilla, and logging in, and navigating to the source/destination folders.) Furthermore, you get a very noticeable boost in file transfer speeds, if you are willing to use a Gigabit Ethernet dongle on your laptop, even a cheap one like I bought (see above), not wifi.

Here's a picture of the NAS I've set up for our small office here:
Inside the NAS kit aluminum case on the top is a 500GB SSD, and there are two more 3.5" drives on the bottom, in enclosures, attached with USB 2.0 cables. OpenMediaVault uses all 3 drives.

Although these enclosures have a good controller chip, the USB3.0 cables provided suck. I would get UAS-related "inflight" error messages as seen above, when using them, for any prolonged period of time.
These error messages went away when using plain old USB 2.0 USB-A-to-USB-B male-male cables (as in, USB "printer cables"), which had the same overall thickness of wire when you compared them side-to-side to the junky USB 3.0 cables, but the USB 2.0 cables have like half the metal wires inside them, which were probably much thicker guage than the junky USB 3.0 cables.
Boo, Orico! Mr. Scissors was not impressed:
We also bought a couple of USB 3.0 cables on AliExpress (don't ask which ones, one was 1.5m, one was 3m), and they too similarly sucked. If Mr. Scissors could speak, he would say, "Off with their heads!":
PS: the reference to Mr. Scissors was a little shout out to Chris Barnatt of explainingcomputers.com.

Thanks for that diagram. Oops, actually, I have the NanoPi Neo 2, not the NanoPI Neo Core 2 (and I've changed the title of this topic accordingly). And I downloaded the wrong thing (although it booted with no complaints!). I'll try again...
BTW: I've been trying the OMV pre-built image (correctly for the NanoPi Neo 2, not Core 2), from here by tkaiser, where I had these glitches. In an attempt to get that USB port on the NAS kit board working more reliably, my plan now is to use the stock Armbian for the NanoPi Neo 2, then use the "softy" menu to install OMV. That way I'll get a newer kernel (which maybe will use that 2nd USB port, on the NAS kit board, more reliably). This will let me jump from an older kernel to a newer one:
Current OMV 4.1 image pre-built by tkaiser:
Linux hostname 4.14.70-sunxi64 #274 SMP Wed Sep 19 12:09:30 CEST 2018 aarch64 GNU/Linux
Current stock Armbian:
Linux hostname 4.14.78-sunxi64 #416 SMP Fri Oct 26 15:54:03 CEST 2018 aarch64 GNU/Linux
I found the USB-related hardware problem, detailed here.

Just to clarify. Drives connected to both the USB port on the NanoPi Neo 2, and the SATA port of the NAS kit work well. It's just a third drive hooked up to the USB port on the NAS kit accessory board where things get sketchy, for that that third drive only.
Hindsight being 20/20, if you want to have a NAS with a backup disk, you would do best to get a NON-SSD 2.5" laptop hard drive (with the longest warranty you can find, like 3yr., and paying a little extra is worth it) to hook up to the NAS kit SATA port (where you'll get, say 4TB max these days), then hook up a 4ishTB 3.5" hard drive (in a good enclosure, like the one I linked to above, with a JMS578), to the USB port on the NanoPi Neo 2 mainboard, NOT the USB port on the NAS kit accessory board. Don't listen to advice about the importance of using an SSD (which is of course going to be way smaller in capacity due to far higher price-per-TB) to get the best random IO speed over UAS. It turns out to be no faster, even on tiny files. For this board, which only has USB 2, (not USB 3) that SSD-related advice is a red herring (when it comes to speed).

Here's what I think the problem is. The USB port on the NanoPi Neo 2 mainboard itself works well with the default UAS driver from the kernel. But the second USB port, which seems to be an afterthought on the NAS kit accessory board, does NOT work well with the UAS driver from the kernel. Why would I conclude this? Because when I put the "problematic" (seeming) drive onto the other USB port (on the mainboard of the NanoPi) the problem went away.
Edit: I found the fix I needed, detailed here.

I hooked a second external 3.5" Hitachi up to the additional USB port provided by the "NAS kit" add-on board. This one is a 6TB. I was wanting to set this up as a backupdrive of my other 2 drives, and serve it out read-only over the network with FTP and SMB. When I formatted it with BTRFS, I got error messages about failed checksums when I tried to FTP my sample 2GB of tiny files out of it! Kernel error messages began appearing during the FTP, such as the following:
Dec 11 15:47:43 filesrv1 kernel: [ 1564.078380] BTRFS warning (device sdc1): csum failed root 257 ino 967 off 41418752 csum 0x394f3c35 expected csum 0x9fc46317 mirror 1
Dec 11 15:47:43 filesrv1 kernel: [ 1564.152892] BTRFS warning (device sdc1): csum failed root 257 ino 967 off 41746432 csum 0xf2ebac76 expected csum 0xa8e57e86 mirror 1
Dec 11 15:47:43 filesrv1 kernel: [ 1564.180123] BTRFS warning (device sdc1): csum failed root 257 ino 967 off 42795008 csum 0x9b4b400b expected csum 0x3b97019a mirror 1
Dec 11 15:47:43 filesrv1 kernel: [ 1564.277908] BTRFS warning (device sdc1): csum failed root 257 ino 967 off 41418752 csum 0x394f3c35 expected csum 0x9fc46317 mirror 1
So I reformatted the drive as EXT4 instead, then tried the same test again. No error messages that time. Strange... BTW: both BTRFS and EXT4 performed the same, when copying data into the drive, and the FTP download speed I achieved (once formatted with EXT4), was 37 MB/sec.
Edit: I changed the USB 3.0 cable. I'm pretty sure the cable that came with the enclosure was flawed. No more error messages now, and the blue light on the enclosure no longer flashes in a warning-like way, when there's no disk activity (and I observed this warning-like flashing, as well as other kernel error messages, when I used a too-long 3-meter-long USB cable previously).

I did an FTP upload test, using all-GbE (no wifi), comparing how the 4TB 3.5" Hitachi (in the JMS 578 enclosure) would compare to the SSD. The 3.5" Hitachi won, slightly: 32.8 MB/sec for the 2GB .zip file (compare to the SSD, which got 29.9 MB/sec), and 18.7 MB/sec for the 2GB worth of tiny files (compare to the SSD, which got the very same 18.7 MB/sec).
Note: SSL was used for FTP. So FTP also kicks SMB1's butt for speed, even when used with SSL. OpenMediaVault made it easy to generate and then use a self-signed SSL cert (for use within my LAN).

I wanted to get some speed tests over SMB (ver 3.11, the default in OMV) protocol, using OpenMediaVault. I used the pre-built image for this board available here. The quick summary is that FTP is way faster than SMB, like 50ish % faster.
Here were some Samba speeds, uploading the same 2GB .zip file, then 2GB worth of tiny files, to the 2.5" Samsung SSD:
Over all-GbE (as in, no wifi between my laptop and the wifi router), 18.3 MB/sec for the 2GB .zip file (would have been 29.9 MB/sec over FTP), and 11.9 MB/sec for the 2GB of tiny files (would have been 18.7 MB/sec over FTP).
Over wifi (as in, there was wifi between my laptop and the wifi router), 14.0 MB/sec for the 2GB .zip file, and 7.8 MB/sec for the 2GB of tiny files.
Here were some Samba speeds, uploading the same 2GB .zip file, then 2GB worth of tiny files, to an external 4TB 3.5" Hitachi hard drive, in a USB 3.0 enclosure which surely has a JMS 578 controller chip (connected to the USB port on the mainboard of the NanoPi, not the USB port on the NAS accesory board):
Over all-GbE (as in, no wifi between my laptop and the wifi router), 18.7 MB/sec for the 2GB .zip file, and 12.1 MB/sec for the 2GB of tiny files.
Over wifi (as in, there was wifi between my laptop and the wifi router), 13.4 MB/sec for the 2GB .zip file, and 8.0 MB/sec for the 2GB of tiny files.
So a plain old 3.5" spinning hard drive, in a good USB enclosure, with a JMicron 578 controller chip, slightly beats an SSD!!

That's fair to point out. I've played with a Qnap TS-251A quite a lot, and the OS is a locked down, stripped down sort of distro, that's clumsy and hard to do anything useful with on the command line (if you're accustomed to Debian, which I am). If, OTOH, you like Qnap's web-based admin interfaces (good for average folk who are not Linux geeks), and accept that you should do virtually everything there (in the web GUI), and avoid the command line (where it's pretty much a nightmare compared to Debian/Armbian), then I say, yah, Qnaps are good.
Having said that, it's not trivial to pare down all the gratuitous bells and whistles that Qnap enables by default. Qnap's default settings make it this sort of all-singing, all-dancing whore of pretty much all networking protocols. I dare you to do an nmap scan on a Qnap appliance (within the LAN) and count all the open ports, which are enabled by default. There are way, way too many open ports, IMHO, if you care about security. So all the paring-down efforts (where you really need to know what you're doing to tighten things up nicely, yet not damage the functionality you really need) seriously takes away from the Qnap's claim to being "easy." A Qnap is actually kind of hard to lock down decently. I've done it, and I could never quite get it the the way I wanted it. There were still open ports I didn't want, yet couldn't disable without also removing some other wanted port.
Also note that Qnap has invented their own software packaging system called "qpkg". You can't "apt-get install" whatever you like, as is the case with Armbian (which is important to me).

OK, I re-ran my Nextcloud tests, shown above, using all-Ethernet.
When uploading the 2GB .zip file, the speed jumped from 10.9 MB/sec (with wifi-from-laptop) up to 17.2 MB/sec (all-ethernet), average. That's considerably closer to my FTP test (which I'm almost certain I did as all-Ethernet), which got me 29.9 MB/sec. @Igor, thanks so much for the great tip.
When uploading the 2GB folder of many tiny files, the speed very slightly improved from 1.0 MB/sec (with wifi-from-laptop) up to 1.1 MB/sec (all-ethernet), average. That's still a far cry from the FTP test (which I'm almost certain I did as all-Ethernet), which got me 18.7 MB/sec:
Note that I used BTRFS on the SSD being uploaded into, for both the FTP test, and the Nextcloud test.