Dmesg reported several errors with the HDD(/dev/sda) when it was connected directly to the on-board usb. I solved it by passing through a powered usb hub. There appears to be current limits to the on-board USB.
The following is a short overview what you can expect from small and big H3 devices when used as a NAS. I chose the least capable device (OPi Lite for $12: not even Ethernet and just 512MB DRAM) and the best possible (OPi Plus 2E for $35: GBit Ethernet, 3 USB host ports exposed that do not have to share bandwidth, 2GB DRAM).
I wanted to test also a H3 device in between with 1GB DRAM but since results are somewhat predictable I dropped the whole idea (the performance bottleneck on all Fast Ethernet equipped devices will be network unless you add the $7.50 for an USB-Ethernet dongle -- see below -- and all other Gbit Ethernet capable H3 devices are not priced competitive)
Low end
3 weeks ago I ordered 2 cheap USB3-Ethernet dongles (Realtek RTL8153 based and recommended by @Rodolfo): http://www.ebay.com/itm/141821170951
They arrived in the meantime so I thought: Let's make OPi Lite an Ethernet device. With our current legacy kernel config and network settings you simply connect the adapter and an Ethernet cable, boot and have eth0 up and running (well, this should apply to most available USB-Ethernet adapters since we enabled every device available in kernel config). The dongle according to lsusb:
Bus 001 Device 002: ID 0bda:8153 Realtek Semiconductor Corp.
Since I want Lite's both USB host ports for disks, I used the OTG port and a Micro USB to USB adapter: a simple iperf test against a GbE device showed 270/300 Mbits/sec (depending on direction).
Power requirements when adding Ethernet using this dongle:
Plugging in the dongle without network cable attached: +700mW
Connecting network cable to USB dongle (GbE!): another +400mW
GbE transmission in one direction (limited to ~300 Mbits/sec): another +800mW
So you can calculate with ~2W additional peak consumption per Ethernet adapter (at least 1.1W more if connected to a GbE network -- this is slightly more than the average 0.9W on Gbit Ethernet equipped SBC when the usual RTL8211E PHY establishes a GBit connection)
I connected then a 3.5" Seagate Barracuda with external PSU (ext4 since with a 3.4 kernel we can not use more interesting filesystems like btrfs -- iozone shows ~35MB/s in both directions), compiled Netatalk 3.1.18 and tested NAS performance from my MacBook (no further tuning except 'echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor' -- without this write performance totally sucks):
Read performance is quite ok given that iperf shows just 270-300 Mbits/sec but write performance needs some tuning (not today). By looking at 'iostat 5' output it was obvious that write buffers were flushed only every few seconds so for normal NAS useage with small files the whole problem doesn't exist and it also should be possible to increase performance (not today). Anyway: search the net for correctly measured performance numbers of other SBC used as NAS and you will be already satisfied given that we're talking here about a $12+$7.50 combination
High end
Orange Pi Plus 2E is -- in my very personal opinion -- the best H3 device available if you think about NAS useage. It is equipped with the maximum amount of DRAM H3 can deal with, has Gbit Ethernet, exposes all 3 USB host ports + 1 OTG and comes with 16GB of pretty fast eMMC. At a competitive price (please keep in mind that you can install the OS on eMMC so you don't have to add the price of an SD card here).
You can attach up to 4 USB disks (with mainline kernel and UASP capable enclosures they will show sequential speeds close to 40 MB/s, with legacy kernel it's ~5MB/s less)
What you see here is the result of Gbit Ethernet paired with way more RAM and a test data size too small (only 300 MB fit perfectly into memory) so this is the increase in speed you will benefit from in normal NAS situations (dealing with files that do not exceed a few hundred MB in size). In case you try to write/read files larger 1 GB (or use software that often uses sync calls to ensure data is properly written to disk) be prepared that USB 2.0 becomes the bottleneck. In these situations sequential transfer speeds between NAS and clients will drop down to ~32MB/s without further tuning (applies to legacy kernel, for mainline see new post coming in the next days)
Anyway: Please keep in mind that these are 'single disk' measurements. You can attach up to 4 disks to an OPi Plus 2E (using individual spindown policies to save energy or RAID modes to improve performance and/or availability), with Armbian defaults at least two of them can be accessed concurrently at full speed (USB2 maxing out at ~35MB/s and GbE being able to exceed 70MB/s easily) and with some tuning that might apply even to 3 disks accessed at the same time.
And if I compare these benchmark results based on defaults (burning Armbian to SD card, firing up the NAS software, measuring performance, done) with what had to be done prior to being able to simply use Armbian as 'NAS distro of choice', eg. these one year old results with A20 then choosing OPi Plus 2E is a no-brainer.
Regarding OPi Lite (or One or the smaller NanoPi M1) as NAS: This was more proof of concept than a recommendation. Being able to use as much RAM as possible for buffers is something especially a NAS / fileserver benefits from. So choosing a device with only 512MB is not the best idea. 'Native' Gbit Ethernet as present on a few H3 devices also clearly outperforms USB based solutions (iperf throughput with a recent Armbian without any tuning: 680/930 Mbits/sec). And if you add costs for USB-Gbit-Ethernet adapter and SD card the smaller boards aren't priced that competitive any longer.
Nope, Ethernet is connected through RGMII and not USB and does not have to share bandwidth. USB disk transfers with legacy kernel max out at 35MB/s (depending on the bridge chip used inside the drive's enclosure -- see some performance numbers). 2 disks combined as RAID-0 on the Plus 2E (where no USB pors have to share bandwidth since no internal USB hub is in use!) should double performance.
As written long time ago... always test individually too: http://linux-sunxi.org/Sunxi_devices_as_NAS#Use_the_right_tools
So have a look at the first link for the iozone calls and measure directly on the board without network/Samba involved. And then you could also do a quick test how fast network is using iperf (Jperf.exe on Windows).
Regarding disks not spinning down. Maybe there's a reason (that's the reason we ship with iotop and iostat). But some disks really ignore sleeping settings and since we're talking about USB disks again the used USB-to-SATA bridge might make the difference (only if the bridge supports SCSI / ATA Translation (SAT) then Linux tools get direct access to drive features like this)
I would check whether you can send the disks to sleep with hdparm (hdparm -Y /dev/sda -- check with -C afterwards), install smartmontools and check disk using 'smartctl -a' and in case the disks do support being sent to sleep investigating with iotop/iostat whether activity happens or trying out scripted approaches like the one below (when you google for 'wwn-0x5000cca222d23f5f ' you get the source) or something like this https://github.com/lynix/hdd-spindown.sh/blob/master/hdd-spindown.sh
BTW: Since we have to move a few customers to SMB (Apple tells devs since years that their old/own protocol AFP is deprecated in favour of SMB and added some proprietary extensions to the SMB protocol) I will test Samba within the next few weeks intensively. Will be using Samba 4.3 and above since this versions contains the Apple adoptions and when I'm at it I'll also have a look at performance tweaks. The servers we're talking about are a 'bit' larger than an Orange Pi (Oracle, Dell, HP servers running Solaris x86, FreeBSD or Linux) but I will give this a try on SBCs too. WIll be interesting how the kind of storage implementation matters (native SATA an A20 vs. USB Mass Storage vs. USB Attached SCSI possible with A20/H3 and mainline kernel)
Marcos A. S. reacted to mikell in H3 devices as NAS