Home > Allwinner H-Series, Debian, Hardware, Linux, Testing > NanoPi NEO NAS Kit Review – Assembly, OpenMediaVault Installation & Setup, and Benchmarks

NanoPi NEO NAS Kit Review – Assembly, OpenMediaVault Installation & Setup, and Benchmarks

NAS Dock v1.2 for Nano Pi NEO / NEO 2 is, as the name implies, a complete mini NAS kit for 2.5″ drive for NanoPi NEO or NEO 2 board. The NEO 2 board is strongly recommended, since it’s not much more expensive, but should deliver much better results due to its Gigabit Ethernet interface. I’ve received two of those kits together with several other boards & accessories from FriendlyELEC, and today I’ll show how to assemble the kit, configure OpenMediaVault, and run some benchmarks.

NAS Kit V1.2 Assembly with NanoPi NEO 2 Board

The only extra tool you’ll need is a screwdriver, and potentially a soldering iron as we’ll see further below.
The metal box is stuff wih accessories so the first thing is to open one or two sides to take out the content. We have the mainboard, NanoPi NEO back plate, NanoPi NEO 2 back plater, a heatsink and thermal set, and a set of 5 screws to tighten the hard drive which mean there’s one extra screw. FriendlyELEC always adds extra screws, and I find it’s a nice touch, as it can be a real pain if you happen to lose one.

Click to Enlarge

Let’s have a closer look at the “1-bay NAS Dock v1.2 for NanoPi NEO/NEO2” board. We have a UAS capable USB 3.0 to SATA brige chip between the two header for NanoPi NEO board (note that the USB connection will be limited to USB 2.0 since the board only supports that), an LED, a USB 2.0 host port for a printer, WiFi dongle, or webcam, the power switch, the power jack, a 3-pin serial header, an I2C connector for Grove modules, and of course the SATA connector.

Click to Enlarge

There’s not much on the other side of the board, except a CR2032 battery slot for the RTC.

Before going further, you’ll need to go to the Wiki, and get the latest OpenMediaVault firmware, in my case nanopi-neo2_debian-nas-jessie_4.11.2_20170531.img.zip, which I then flashed with Ether program to a micro SD card..

Once this is done, install the heatsink and thermal to your NanoPi NEO 2 board, and insert the micro SD card into the board.

Notice that I also soldered the headers. While it would be obvious to people would have looked at the pinout diagram, I’ve read some people have justed connect the board using the (pre-soldered) 4-pin header, as they may have believed it was a USB header, but it’s just the serial console instead, and obviously the hard drive was not detected. If you don’t feel like soldering the headers to the board yourself, make sure you tick the option “with pin headers soldered” when ordering. It just costs $1 extra.

Now we can insert our board into the “1-bay NAS Dock” board, instead the hard drive, and optionally an I2C module. I connected an I2C OLED display i the picture below for illustrate, as using the display would require cutting out the case. Some people may want to connect an I2C temperature sensor instead.

Click to Enlarge

I used four screws to tighen the hard drive on the other side of the board, and install a CR2032 battery for the real-time clock.


Finally, you’ll need a 12V power supply with at least 1A, but I could not find any (safe) spare ones so I used Maxoak K2 power bank instead, since it can output 12V @ 2.5 A max.


OpenMediaVault Setup on NanoPi NEO 2 Board

So I connected everything, and applied power, but the board would not boot with the Ethernet Link LED blinking in a regular fashion, meaning something was very wrong. So I took out the board, and connected a serial debug board, connect to the console via minicom using 115200 8N1, and that’s what I got:


The boot was just stuck there. I re-inserted the micro SD in my PC, and I could see both boot and rootfs partitions, so everything looked good.
Then I powered the NanoPi NEO 2 board with a 5V/2A power supply only, and the boot succeeded:


Then I went back to the 12V power input on NAS Kit with the power bank and the boot succeeded. Very strange. It turns out the board would not boot most of the time, but the symptoms are not reproducible 100% of the time. This kind of random behavior is usually a timing or distorted signal issue. So I thought the micro SD card might not play well with the board, and the power bank signal might not be so clean. So I first flashed another micro SD card, but same results. I used another 12V/5A power supply, and it did not really help either. Finally, I used another NanoPi NEO 2 board and it appears to be stable.

You can find the board using FriendlyELEC.local if bonjour services are running in your computer:


Alternatively, you could check out the IP address in other ways. In my case, I just type friendlyelec.local in Firefox to access the web interface. The default username and password are admin and openmediavault.

Click to Enlarge

After login, you can access the dashboard showing system information, and which services are running. You may want to disable the services you don’t need.

Click to Enlarge

You can go to Storage->Physical Disks to check if your hard drive has been detected. No problem for me here with a 931.51 GiB drive detected.

Click to Enlarge

You may then want to setup a fix IP address. There are various ways to do this but I went to Network->Interfaces and set eth0 to a fixed IP address. You’ll be asked to apply the changes once it’s done.

Click to Enlarge

I also changed the hostname to CNX-NEO2-NAS in the General tab.

After that I decided to address some security issues. First by changing the administrator password in General Settings->Web Administrator Password.

I then went to Access Rights Management->User to find out there were two pre-configured users: pi and fa. I deleted fa user, changed pi’s user password, and added it to ssh group. It’s actually even probably better to just delete both user, and create your own.

The root user is not shown, but you’ll want to login as root through ssh first and change the password, as the default password is fa. Once it’s done, you’ll have better security, and your system should not be easily accessible via basic “hacks”. For more security, you’ll still want to install an RSA certificate. A self-signed one should do if you plan to use it only in the local network, but you may also consider a free Let’s Encrypt certificate instead.

We can now take care of the hard drive. I went to Storage->File Systems, and clicked on +Create file system which will let you choose between BTRFS, EXT3, EXT4, XFS, and JFS. I’ve gone with EXT4 first.

Click to Enlarge

After a few minutes you drive should be formatted, so we can configure network shares. I want to use SAMBA and SFTP to transfer files for the purpose of this review, so I went to Access Rights Management->Shared Folders to add a new share called HDD for the root of of hard drive. You may want to add multiple share if you plan to split videos, documents, music and so on.

Click to Enlarge

I clicked Save, and selected ACL to add permissions to pi and admin users. You can add whatever users you plan to use to access the share.

Click to Enlarge

That share3d folder can now be assigned to the services you plan to use. SFTP is enabled by default when SSH is running, so I create a SAMA/CIFS share by going to Services->SMB/CIFS->Shares to add the share.

Click to Enlarge

Browsing the Network with Nautilus would show both cnx-neo2-NAS – SMB.CIFS and cnx-neo2-nas – SSH (SFTP) shares.

Configuration is now complete. I have not find a clean way to power off the system, so I normally open a terminal session via ssh and run the shutdown now command. A software button to turn of the NAS would have been a nice features on the kit.

I also often encountered the error “Software Failure. Press left mouse button to continue. Session not authenticated.” before the session timeout is set to 5 minutes. If you prefer a longer timeout, you can change it in General Settings->Web Administration.

In case you want to use the RTC, you may first want to set the timezone:


Check the date is correct, and write it to the hardware clock:

before reading it back.


You can test it by rebooting the board without the Ethernet cable:


Perfect! You’d just have to make sure the “set” command is run automatically at boot time if the time in the RTC is set. It would be good if FriendlyELEC updated their image to do that automatically at boot time.

NAS Dock V1.2 + NanoPi NEO 2 Benchmarks

Since I can now copy files and folders over SAMBA and SFTP, we can start running some benchmarks to evaluate performance. I’ll use EXT-4, BTRFS, and XFS file systems on the hard drive, and run iozone to specicially test storage performance, following by copying large and small files over SAMBA or SFTP to test real-life NAS performance. For large file copy, I’ll use a folder with 7 large files totaling 6.5 GB, and for small files, I’ve done a fresh checkout of the Linux kernel in my computer:


and removed symlinks since they may cause issues during copy, as well as .git directory with a huge 1.8GB file:


The end result is a directory with 64,013 files totaling 748.6 MB.

Iozone results

EXT-4:


BTRFS:


XFS:


I’ve taken results with 16384kB reclen for read, write, random read and random write values to draw a chart, since most people are likely going to store large files in their NAS. The smaller reclen could be interesting if you plan to handle smaller files.

All three file systems have a very good read speed of around 40 MB/s, but BTRFS write appear to be the fastest among the three, with EXT-4 being the weakest at around 25 MB/s. But for some reasons, those results are useless in practice, as we’ll see below. Finding out the exact reason would possibly require studying and profiling iozone and the kernel source code which would be outside of the scope of this review.

File copy over SAMBA and SFTP

Results for large files in minutes and seconds.

File Copy  Large Files SMB SFTP
Write Read Write Read
EXT4 02:49.00 02:40.00 03:54.00 04:15.00
BTRFS 03:20.00 02:40.00 03:48.00 04:32.00
XFS 02:45.00 02:38.00 03:36.00 04:23.00

Chart converted to MB/s.

Read and Write Speeds in MB/s

First, we can see very good read performance from the NAS (NAS to my PC)  with 41 to 42 MB/s close to the theorethical limit of a USB 2.0 connection. Write speed is a a little different as the files were transferred more slowly with BTRS, and around 40MB/s with EXT-4 and XFS.  Since SFTP is encrypted the transfer speed is roughly the same for all three file systems. Overall the file system you choose does not really impact performance with large files.

Results for small files in minutes and seconds.

File Copy  Small Files SMB SFTP
Write Read Write Read
EXT4 15:26.00 18:34.00 09:02.00 12:48.00
BTRFS 18:48.00 18:02.00 10:30.00 11:30.00
XFS 17:33.00 18:22.00 09:18.00 12:35.00

Chart converted to MB/s.

Transferring a large number of small files over SAMBA is really slow, and barely faster over SFTP. Again,there aren’t any significant differences between file systems here.  If you are going to transfer a large number of small file over the network, you may want to either compress the files before transfer, or compress the files on the fly using the command line:


It took just 1 minute and 49 seconds to transfer all 64,013 files, or over five times faster than SFTP write to XFS, at around an effective 6.86 MB/s. So knowing your tools may matter as much as having the right hardware.

I was going to run a last part after enabling optimizations provided by tkaiser, but it turns out FriendELEC has already done that in their firmware image.

If you want to reproduce the setup above, you’ll need to purchase NAS Kit v1.2 for $12.99, and a NanoPi NEO 2 with soldered headers for $15.99. If you don’t have a 2.5″ hard drive, you’ll need to add this, as well as a 12V power supply which you could purchase locally, or on FriendlyELEC website for under $10. All in all that’s cheaper than a similar kit with a Raspberry Pi 3 board, and you’ll get close to four times the SAMBA performance for large files since RPi 3 will be limited to 10 to 12 MB/s due to the Fast Ethernet connection.

  1. Daniel
    June 18th, 2017 at 17:14 | #1

    Mine will arrive in 2 weeks. Can’t wait!

  2. tkaiser
    June 18th, 2017 at 17:52 | #2

    Thanks for the numbers and taking care of details (like improved Samba settings in FriendlyELEC’s OMV image).

    Just two notes: By looking at the iozone numbers with btrfs it’s obvious that random write performance is ‘benchmarking gone wrong’, with all three filesystems random reads are around ~100 IOPS (you need to divide the iozone numbers that are KB/s through the block size) and random writes are ~185 IOPS with etx4 and XFS vs almost 2000 IOPS with btrfs. In other words: there’s something different at the VFS layer and this test does not report disk speeds but something else with btrfs. Just another example of a benchmark result that should not be used but simply dropped since ‘numbers without meaning’ 🙂

    It seems you used three different partitions for the filesystems tests? When doing this with HDDs this can affect performance numbers due to ‘position’ of the partition (with most 2.5″ HDD even when USB2 is another bottleneck). All modern HDD use a feature called ‘zone bit recording’ storing more sectors on the outer tracks than on the inner ones. And therefore data rates at the begin of the disk (outer tracks) is much much higher than at the ‘end’ (inner tracks). Details: https://forum.armbian.com/index.php?/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=15319

  3. June 18th, 2017 at 18:07 | #3

    @tkaiser
    I did mention we should ignore iozone3 numbers since some are lower than numbers with SAMBA…

    I reformatted the drive for each test, so the full 1TB (931MB) was used for each partitions.

  4. tkaiser
    June 18th, 2017 at 18:25 | #4

    @cnxsoft
    Good to know, in the meantime I checked FriendlyELEC’s kernel repo (github.com/friendlyarm/linux/tree/sunxi-4.11.y) and saw they’re using ondemand as default which might be another possible explanation for some weird looking numbers.

    Might be worth a simple retest with ext4 and cpufreq governor set to performance. And if then numbers improve it’s time to look into /etc/rc.local for something like this:

  5. tkaiser
    June 18th, 2017 at 20:54 | #5

    Unfortunately their english wiki page is still not updated.

    It’s still showing JM20329 as USB to SATA bridge and misses to mention that with the PCB 1.2 version also 3.5″ HDDs should be directly useable (according to schematic VDD_SATA_12V is routed to the three appropriate pins on the SATA power connector)

    @cnxsoft: Are you able to do a quick test with a 3.5″ HDD? In that case a 12V/2.5A PSU would be a good idea.

  6. June 19th, 2017 at 04:21 | #6

    This looks promising. But too bad they do not offer a 1GB version of the Neo2. 🙁

  7. June 19th, 2017 at 09:47 | #7

    @tkaiser
    Sorry I can’t try. This would require a SATA male to female cable. I only have female to female cables.

  8. theguyuk
    June 19th, 2017 at 10:24 | #8

    @Mike Schinkel
    Maybe if enough people make the case for it and uses they might?

  9. tkaiser
    June 19th, 2017 at 12:26 | #9

    @Mike Schinkel
    For which use case do you need more DRAM?

    @cnxsoft
    I was talking about using the PCB to directly connect to a 3.5″ HDD without a cable in between.

  10. roel
    June 19th, 2017 at 14:17 | #10

    70$ shipping to Belgium. It’s twice the price of the kit!

  11. June 19th, 2017 at 14:24 | #11

    @tkaiser
    Oh OK. I thought the SATA connector was higher on 3.5″ drives… But it fits perfectly.
    It’s detected, and I can mount it:

    I’m using a 12V/5A power supply. FriendlyELEC should make another case for a 3.5″ drive. That would allow for more capacity.

  12. tkaiser
    June 19th, 2017 at 14:48 | #12

    cnxsoft :
    I thought the SATA connector was higher on 3.5″ drives… But it fits perfectly

    Yeah, there is no different SATA connector for 2.5″ or 3.5″, the only question is always whether 12V is available on power pins or not. Thank you for confirming, I hope FriendlyELEC starts to sell the NAS 1.2 PCB separately too.

  13. June 19th, 2017 at 14:52 | #13

    @tkaiser
    That’s weird they only sell v1.0 board separately. I thought they would have just phased out that board.

  14. theguyuk
  15. tkaiser
    June 19th, 2017 at 15:11 | #15

    @cnxsoft

    Availability is ‘Pre-Order’ so I hope they replace it with v1.2 soon. Maybe they could sell the remaining v1.0 PCBs as part of a really cheap ‘DYI Fast Ethernet NAS kit’ with a bundled H3 NEO — pin headers soldered — since there JM20329 doesn’t matter that much. With a price below €22 including shipping (no customs, no VAT) they could target European users that want to choose an RPi 3 for OMV instead. Same performance, same functionality (OMV) but better price and integration (no external disk and no cabling needed)

  16. tkaiser
    June 19th, 2017 at 17:14 | #16
  17. Vai
    June 19th, 2017 at 17:43 | #17

    What is the maximum hard drive size it supports?

  18. roel
    June 19th, 2017 at 18:00 | #18

    @tkaiser
    I already noticed it was the old version on the aliexpress store. BTW it’s also only the kit without the nanopi-neo. I don’t think some vendor will be interested in Belgium. They are alienated here for such things. In the Netherlands they are more open to it.

  19. tkaiser
    June 19th, 2017 at 18:07 | #19

    @Vai
    With the above 1.2 version of the kit there’s no limitation. JMS567 supports SATA drives of any size. Be careful when following obscure links to the old 1.0 variant of this kit or at least do some research on your own whether JM20329 used there is capable to deal with disks that exceed 2.2TB in size (32 bit integer overflow with old USB-to-SATA bridges) and can cope with Advanced format 4K drives.

  20. tkaiser
    June 19th, 2017 at 18:22 | #20

    @roel
    Well, then it’s time to send a daily email to conrad.be (they’re ALLNET resellers and added recently some NanoPi models so show them that there’s demand for more 😉 )

    BTW: I’m personally not interested in the 2.5″ enclosure solution at all since if I want to combine such a H5 based OMV thingie with 2.5″ disks I can choose any of the available options (most probably preferring Orange Pi PC 2, Prime or soon to be released NanoPi M1 Plus 2 if my use case requires more DRAM). The beauty of this solution here is the $6.99 PCB being able to be fed with any of the usual 12V bricks and allowing to attach/power a 3.5″ disk. So still looking forward for this PCB rev 1.2 appearing in FriendlyELEC’s shop 🙂

  21. nobe
    June 19th, 2017 at 21:12 | #21

    do you guys know what’s the HDD operating temperature inside the case ?

    https://static.googleusercontent.com/media/research.google.com/en//archive/disk_failures.pdf
    according to this study (fig 5), failure rates of 3+ year old drives tend to skyrocket when avg operating temp exceeds 40°C.
    and imho, this case shoudn’t be such a S.M.A.R.T. choice (almost no cooling, that’s what i call a mini-oven-case)

    you could get some nice info using these commands :

    sudo apt-get install smartmontools
    sudo smartctl /dev/sda -a | grep -i temp

    PS: you should always backup your data :p
    PPS: note that i’m talking about HDD, i have no idea about how SSD behave regarding operating temperature

  22. tkaiser
    June 19th, 2017 at 21:39 | #22

    nobe :
    do you guys know what’s the HDD operating temperature inside the case ?

    You realized that only 2.5″ disks fit into the enclosure? Unless you take 10k WD VelociRaptors without their IcePack frames there’s no need to worry about temperatures at all. The better idea is using the -x switch with smartctl since this also allows accessing the so called ‘SCT logs’ if available and then you get also something like this:

    This is a Notebook HDD currently used in an external enclosure to do backups, all thermal data fine.

    Wrt to the Google study it’s always amazing what people extract from data. The study shows clearly the opposite of what you claimed 😉 ‘The figure shows that failures do not increase when the average temperature increases. In fact, there is a clear trend showing that lower temperatures are associated with higher failure rates’. Also ‘One of our key findings has been the lack of a consistent pattern of higher failure rates for higher temperature drives or for those drives at higher utilization levels’.

    That’s the data. Only for some 3 or 4 year old drives there was a somewhat different correlation (correlation != causation). This study is from 2006 and tells clearly: ‘The data used for this study were collected between December 2005 and August 2006’ so some statistical correlation for some disks that were put into production in 2001/2002 should matter for any decision today? Really?

  23. nobe
    June 19th, 2017 at 23:35 | #23

    come on tkaiser… imho the text you quoted is more of a general interpretation.

    The data is shown by the graphs, not the text.
    And my “claim” (i don’t like this term, it’s more like how i interpret the graphs) took into account temperature AND disk age.

    Figure 2 clearly shows that AFR (average annualized disk failure) is much higher starting with 2+ years old drives.
    Is my reading of this graph wrong ? i don’t think so.

    Figure 5 adds in ‘average drive temperature’. And yes, AFR of 3 years old drives skyrockets when their temp >= 40°C.
    Is my reading of this graph wrong ? once again, i don’t think so.

    though, i agree with you that the data is old. but can you provide more recent data ? i just can’t…
    should i make as if this study didn’t exist ? really ?

  24. tkaiser
    June 20th, 2017 at 00:21 | #24

    nobe :
    come on tkaiser… imho the text you quoted is more of a general interpretation.

    It’s what’s called the result after analyzing all the data. Of course you’re free to ignore this based on looking at few graphs there 🙂

    If you really read through this study you’ll find references to even older studies all mentioning a correlation between high temperatures and failure rates. Google’s numbers show this also for disks from 2001 and 2002 (you know that we’re talking here partially of ATA/IDE disks and not even SATA? And Google (mis)used desktop HDDs for 24/7 operation just as the Backblaze folks do today –> you might want to check http://www.backblaze.com/blog/hard-drive-temperature-does-it-matter/ and their summary: ‘I found that overall there is no correlation between temperature and failure rate.’ — I’ll leave it as an excercise for the reader to find out which methodological mistakes were made here 🙂 )

    Anyway: If you feel affected by some statistical correlations that are all based on disks that are at least 15 years or older, then… well. We’re still talking here about energy efficient 2.5″ disks and even with a ‘NAS benchmark’ running NEO2 + HDD won’t be able to exceed overall consumption of 5W or maybe 7W. Ever seen a 7W heater? 😉

    Really, temperatures are no concern but maybe Jean-Luc can run a NAS benchmark like Helios’ LanTest (needs a Windows box though) with 3 times 10GbE settings, then wait 10 minutes and provide output of
    smartctl -l scttemp /dev/sda

  25. Dcbasso
    June 20th, 2017 at 02:05 | #25

    This device support more them 1tb disk?!

  26. tkaiser
    June 20th, 2017 at 02:10 | #26
  27. June 20th, 2017 at 10:06 | #27

    @nobe
    Results of the command after copying a large (~100GB) file over SAMBA.

    CPU is around 75% idle during the copy so it’s not a worst case scenario. Room temperature is around 30 C.

    Full output from smartctl /dev/sda -a -d sat command: https://pastebin.com/NbH0iJyE

  28. June 20th, 2017 at 10:07 | #28

    @cnxsoft
    Command with x switch:

  29. tkaiser
    June 20th, 2017 at 11:30 | #29

    cnxsoft :
    CPU is around 75% idle during the copy so it’s not a worst case scenario. Room temperature is around 30 C.

    So nothing to worry, disk temperature inside the enclosure is not even 15°C above ambient temperature. BTW: ‘grep -i temp’ is wrong to get the SCT logs, eg. temperature logging: this is a nice feature to get temperature variations eg. after running a heavy benchmark (heavy != NAS mode), looks then like this at the end here: https://pastebin.com/pVrPZr9Q

    With 2.5″ HDDs that are better choices if you fear heat (Samsung/Seagate Spinpoint — compare the min/max values with the Toshibas from above) it looks like this for example (Spinpoint M7 AKA SAMSUNG HM500JI):

    There’s a nice different too if you prefer your disks spinning down when inactive. A ‘smartctl -a’ wakes the disk so it spins up while a ‘smartctl -l scttemp’ gets just the recorded temperature records without waking up the disk and that way you get also temperature history for the drive while in standby state (unfortunately not all drives support SCT temperature logging). Current temperature is then

  30. tkaiser
    June 20th, 2017 at 12:06 | #30

    BTW: I photoshopped yesterday the combination 3.5″ HDD with the NAS 1.2 PCB: http://kaiser-edv.de/tmp/NumpU7/NAS_Kit_with_3.5_disk.jpg

    Looking forward to just get the PCB, a 3.5″ HDD and then combine it with NEO2 or even NEO Plus 2.

  31. June 20th, 2017 at 16:40 | #31

    @tkaiser
    The photoshop looks about right (dimensions wise).

  32. nobe
    June 20th, 2017 at 16:40 | #32

    @cnx
    thx running for the test

    @tkaiser
    it looks like the backblaze article mentions HDD which average temperature <= 38°C.
    obviously i wasn't talking about this scenario : google graphs show AFR = 40°C.
    but at least there the text (interpretation) doesn’t seem to contradict the graphs (data vizualisation).

    and backblaze mentions another article from microsoft and university of virginia : http://www.cs.virginia.edu/~gurumurthi/papers/acmtos13.pdf
    in section 4.2, this study :
    – correlates higher AFR with higher temperature (there seem to be much more interesting information in there, but i don’t have the time to read it completely)
    – points out it’s contrary to the google study (‘pinheiro and al 2007’)
    and i’m not surprised here. there’s definitely a “by drive age” bias in google study. this is shown by the 2 graphs i mentionned in a previous comment which seem to contradict their own interpretation.

    btw, thx for telling about the “smartctl -l scttemp” option, that’s very interesting.

    and lastly, you probably won’t care but i just dropped my 2.5″ external hard drive when i wanted to try this option, now it seems dead T_T

  33. nobe
    June 20th, 2017 at 17:06 | #33

    oh… part of my previous comment doesn’t appear, i think it was somehow commented out

    google graphs show AFR inferior or equals 5% when temp superior or equals 40°C

  34. nobe
    June 20th, 2017 at 17:14 | #34

    erratum : when temp inferior or equals 40°C ^^;

  35. tkaiser
    June 20th, 2017 at 18:10 | #35

    nobe :
    backblaze mentions another article from microsoft and university of virginia

    You should really read the studys you want to rely on. I know this paper since years and it’s IMO a good example why statistics is so hard. The folks who did the data research wanted to show a causation of higher temperatures with higher failure rates. They were so focused on temperature that they simply forgot about everything else, especially vibrations. They mention ‘vibrations’ as follows: ‘We currently do not have metrics that expose the level of induced vibration, and measuring the impact of vibration is one of our projects that are currently underway’ and then simply forget about it and focus on aging and temperature only. I would call this already stupid.

    If you look at the graphs at page 12 it’s obvious that position of drives/servers matters more than temperature so you have to think about what’s different wrt position and that might be that the inner drives are exposed to more vibrations as the outer drives (that show similar low failure rates but totally different averaged temperatures).

    All this ‘significant correlation’ babbling is useless if you’re already biased and want to use statistics to make your point. For example there is a ‘significant correlation’ between shoe size and reading capabilities. Those human beings with very small feet don’t read good or at all (those are called children BTW). If you do statistics wrong you make a causation out of a correlation and conclude that the larger the feet the better the reading skills. That’s what happens all the time 🙂

    Back to real numbers, I made another test in the meantime. Samsung SpinPoint M7 in pretty small ABC plastic enclosure together with an SBC (Olimex Lime2). The thing is in a rack, temperature in the cabinet is a constant 18°C. HDD temp when sleeping is 32°C or 33°C. Few iozone benchmarks using sequential and random IO workloads ran between 11:15 and 11:30 afterwards I let the disk spin idle:

    SoC and PMIC have internal thermal sensors. When the HDD is sleeping with normal workloads they’re both at 39°C but when running the iozone tests temperatures increased up to 43°C: https://pastebin.com/eAjWHQKU

    While the HDD is spinning but idle HDD temp remains at 38°C and SoC is 1°C above normal level (so that’s HDD heat dissipating over to the SoC) while PMIC is 2.5°C above normal level (PMIC temperature rises with load). In other words: As expected everything’s fine.

    Final comment: I hope you know that you don’t need to care about statistical data for fleets of HDDs if you’ve only one or a few disks? They don’t care or know about statistics and die within a few months or survive 10 years or longer. The above numbers are only interesting if you plan to use at least hundreds (better thousands) of disks since only then you can benefit from statistical results if they show a causation and not just correlations and you never looked into whether that’s the real cause.

    Wrt disks and vibrations please visit youtube and search for ‘shouting in the data center’ 🙂 And another nice example why statistics is complex and correlations are no causations can be found on the web searching for ‘stork babies statistics’.

  36. Andy Chentsov
    June 20th, 2017 at 18:56 | #36

    Does anyone use OMV on an SD card with read-only root?

  37. tkaiser
    June 20th, 2017 at 19:14 | #37

    @Andy Chentsov
    If you use any of the Armbian based OMV builds from here https://sourceforge.net/projects/openmediavault/files/Other%20armhf%20images/ (or the most recent ones for ODROID-C1/C2/XU4 at the same location) you don’t need to care about that. Due to disabled monitoring and optimized settings (Armbian settings + folder2ram) SD card writes are reduced to the absolute minimum. If you don’t trust in SD cards at all you could create a small partition (4GB are already sufficient) on any of the disks and move the rootfs over using ‘nand-sata-install’. SD card has to remain in the slot but only the bootloader is read so then the SD card is really read-only.

  38. Andy Chentsov
    June 21st, 2017 at 18:00 | #38

    @tkaiser
    Thanks for the reply.
    I would like to have a guarantee that the file system will not be broken if unexpected power off, so I’d like to make the root filesystem read-only.

  39. Drone
    June 21st, 2017 at 18:29 | #39

    Thanks, nice review…

    Was the bad NanoPi NEO 2 board unstable by itself if unplugged from the NAS board? Maybe the NAS board is causing the instability. What did the manufacturer have to say about this? Anyone else with out-of-the-box unstable or dead NanoPi NEO 2 hardware, with or without the NAS board?

    Since you said SFTP is running, an alternative to running SAMBA is to generate a key pair via OpenSSH and register the public key in your file browser (it’s easy to do in Nautilus, search online for a tutorial). Now your shared device will appear in your file browser under Network or Bookmarks and work just like a SAMBA share, but without the bloat and insecurity of actually running SAMBA. Note however, SFTP shares may be slower than SAMBA (roughly 15%-%50% depending on many factors like FS type, read or write, file size, number of files, media format, media interface, etc.)

    SAMBA was recently found to have some serious bugs and was patched on all mainstream distros, so I would suggest research into this plus figuring out how to patch the NAS box OS (good luck with that).

  40. tkaiser
    June 21st, 2017 at 19:39 | #40

    Andy Chentsov :
    I’d like to make the root filesystem read-only.

    Not possible and useless anyway since power losses could also corrupt data on the NAS shares. If you expect power problems simply fix them first! You can use any UPS here since power draw of such an idle NAS will be as low as 1W (a little bit more if you use an overrated 12V PSU brick).

    Drone :
    SAMBA was recently found to have some serious bugs and was patched on all mainstream distros, so I would suggest research into this plus figuring out how to patch the NAS box OS (good luck with that).

    LOL! FUD galore! OMV3 is based on Debian Jessie, Samba packages are those from upstream Debian repositories so Debian’s security team will provide fixes. I can’t speak for FriendlyELEC’s OMV image (since never used or tested) but the Armbian based OMV variants enable ‘unattended upgrades’ so as long as you let your NAS box access the Internet you get security fixes automagically on a daily basis!

    For anyone concerned about Samba vulnerabilities and OMV: Simply allow unattended upgrades and update regularly! And check https://security-tracker.debian.org/tracker/source-package/samba if in doubt.

  41. theguyuk
    June 21st, 2017 at 19:45 | #41

    @tkaiser

    You should given your experience do your own blog or a PDF book.

    Other people still promote Banana Pi !?

    https://simplenas.com/

  42. tkaiser
    June 21st, 2017 at 21:12 | #42

    theguyuk :
    Other people still promote Banana Pi !?

    The old Banana Pi with A20 SoC make up for nice little NAS boxes but you have to avoid the OMV images from simplenas.com — they are old, outdated, use broken settings and perform not that great. I’ve tried to explain that to Cyryllo (the one behind the site) several times in the past but have given up. Fully supported OMV images for the Bananas worth a try you’ll find in official OMV download section: https://sourceforge.net/projects/openmediavault/files/Other%20armhf%20images/ (they’re based on Armbian’s Debian flavour, use Armbian settings and a few improved tweaks for OMV to improve NAS performance)

    While those old A20 based Bananas have ‘real SATA’ in most real world scenarios they’ll be outperformed by this cheap NEO2 NAS box here especially when using btrfs with ‘compress=lzo’ mount option (has to be set manually in OMV’s /etc/fstab). But same applies to all the other GbE enabled H5 boards once mainline kernel is ready for them (4.13 I would assume so just few months more waiting 😉 )

  43. Andy Chentsov
    June 22nd, 2017 at 15:09 | #43

    @tkaiser
    UPS is a good thing, but using a 200-300W UPS to power the NAS on a NanoPi is like “use a cannon to kill a fly.”

  44. tkaiser
    June 22nd, 2017 at 15:21 | #44

    @Andy Chentsov
    That’s the reason we use Olimex Lime2 for small NAS boxes. There you simply plug in a battery and are done since Olimex engineers are not that stupid as others (talking about Bananas here) and a connected disk runs from battery if needed.

  45. Andy Chentsov
    June 22nd, 2017 at 16:09 | #45

    @tkaiser
    Olimex Lime2 has an old A20 SoC. It would be nice if FriendlyArm engineers added the LiPo battery connector to the NAS Dock.

  46. tkaiser
    June 22nd, 2017 at 17:11 | #46

    @Andy Chentsov
    Adding a battery connector isn’t enough, you need charging circuitry and also some logic how to switch between power sources if needed. That’s the (only) reason why tablet SoCs like A20 are nice for small NAS because they’re accompanied by PMICs (AXP209 in A20’s case) that handle this. TV box SoCs like the one we’re talking here about (H5) miss this.

    But just adding a battery connector and PMIC is also not sufficient as you can see by looking at the ‘designs’ from manufacturers known as ‘brain damaged retards’. On almost all Banana Pi for example you find a battery connector and a PMIC but those ‘engineers’ never think about what they’re doing and so connected disks won’t be powered when running from battery.

  47. Andy Chentsov
    June 22nd, 2017 at 17:26 | #47

    @tkaiser
    I meant to add the connector -> to add the ability to use the battery for power backup (with switching logic).
    This can be achieved not only by relying on SoC, but adding logic on its own, for example, to the NAS Dock board.

  48. theguyuk
    June 22nd, 2017 at 18:27 | #48

    Would this 2015 RPI video suggest any diy solutions https://m.youtube.com/watch?v=qev1E7bqNjA

  49. tkaiser
    June 22nd, 2017 at 19:09 | #49

    @Andy Chentsov
    Currently the NAS kit is rather cheap ($7 without enclosure, an additional $6 for enclosure + heatsink) and if you do a web search for ’12v ups’ you find only solutions twice that expensive. By choosing a tablet SoC it’s just adding PMIC, boost converter and a common battery connecter and you’re done (regarding the latter: some manufacturers also known as brain damaged retards manage to use proprietary battery connectors you can’t find a single battery for since not even the retards sell batteries that would fit).

    If I would want to combine a H5 based NAS with UPS functionality I would most probably choose an Orange Pi PC2 (or Prime if my use case needs more than 1 GB DRAM) and combine it with an USB powerbank that can be charged and powers devices at the same time (only a few do!). On the Orange Pi the horizontal USB receptacles share one current limiter so USB powered disks should always be connected to the upright USB port instead.

  50. June 22nd, 2017 at 19:28 | #50

    @theguyuk
    That’s one solution, but this won’t work with all power bank though, as some will take some small time to switch between mains and battery power to the board may reboot. Some power bank (like the 50A one I used in this review) may just shutdown after a power failure, and you may have to press the button manually again to turn it on.

    This should also be tested under load.

  51. tkaiser
    June 22nd, 2017 at 19:48 | #51

    cnxsoft :
    @theguyuk
    That’s one solution

    This is not a solution since the NAS kit wants to be powered with 12V. To combine it with an USB power bank you would also have to add an external step-up converter to do the 5V–>12V conversion while internally there sits a step-down converter to get back to 5V. Only a nice way to waste some energy and generate heat unnecessarily.

    With an USB power bank I would prefer a 5V setup instead as outlined above (get an OPi PC2, FriendlyELEC’s OMV image, exchange the .dtb file and you’re done. Or wait few months until official OMV images appear on Sourceforge for all relevant H5 boards anyway. On the other hand now that RK3328 USB3 performance is known H5 boards look somewhat boring if it’s about the NAS use case)

  52. June 22nd, 2017 at 19:54 | #52

    @tkaiser
    You don’t necessarily need a USB power bank, just a 12V power bank.

  53. Andy Chentsov
    June 22nd, 2017 at 20:03 | #53

    @cnxsoft
    How can the power banks inform the operating system to switch to a battery so that it can automatically shutdown if the power does not appear for a certain period?

  54. tkaiser
    June 22nd, 2017 at 20:48 | #54

    @Andy Chentsov
    You can use the inavailability of a networked device as a ‘mains is gone’ indicator (a variation of the heartbeat principle) or you take the solder iron and use power bank leds (that usually start to blink if capacity gets low) as GPIO input of an SBC. All of this not necessary with appropriate SBC for this use case like Olimex’ Lime2 since there you can read out battery capacity/voltage through sysfs and act on accordingly 🙂

  55. Andy Chentsov
    June 23rd, 2017 at 16:11 | #55

    @tkaiser
    To check the lack of power using the network devices is not reliable, because the network may disappear when the router is rebooted.

    I was able to run OMV on the read-only root partition using overlayfs, scripts and patches for this you can see here https://gist.github.com/andyduke/3da146828e1fded905932ee56225802f.
    Now I tried it in a virtual machine, next week I’ll try it on NanoPi Neo2.

  56. doru
    July 29th, 2017 at 23:45 | #56

    I made few tests in that in that configuration:
    – software: Dietpi OS v.154 with samba installed through Dietpi menu
    – hardware: 2.5″ hdd, Western Digital 320 GB with file system NTFS, one partition
    – main computer have Win8.1×64
    – all my network interfaces are gigabit, router-switch-main PC…
    After few moments after boot I transfered:
    – a big file (2.2GB) from main PC to Nanopi Neo2 with 17 ~ 20 MB/s
    – 1395 files from main PS to Nanopi Neo2 with minimum 13 MB/s
    But, after a half an hour the whole Nanopi Neo2 and aluminium case become very hot.
    The CPU temperature don’t drop below 68 degree and the aluminum case is also very hot when I touched with my hand.
    The transfer speed dropped:
    – the same big file – 2 MB/s
    – the same small files – 2 MB/s

    Seems to be unusable because of highest temperature.
    Any other configuration, tests and temperature?

  57. July 30th, 2017 at 10:59 | #57

    @doru
    If the 68 C is the CPU temperature reported by the system, then it’s not too high. Maybe it’s another issue.
    In case, it’s really a CPU throttling issue, then it can be mitigated in several ways:
    Hardware – Make sure the thermal pad and heatsink are properly installed. I guess some people will forget to remove the plastic covers on the thermal pad.
    Software – The way to CPU governor is handled matter too, so I’d check the OMV image released by FriendlyELEC above, and/or Armbian images. You can also adjust the power consumption (and indirectly heat dissipation) using armbian-config

  58. tkaiser
    July 30th, 2017 at 15:34 | #58

    doru :
    I made few tests in that in that configuration:
    – software: Dietpi OS v.154 with samba installed through Dietpi menu

    O my good, that’s already worst case. DietPi is about marketing bullshit (lightweight, diet) and guiding clueless users in a menu driven way. It totally focusses on userland and don’t pays attention to the relevant stuff on small ARM boards (kernel, settings). As the creator says: ‘DietPi for NanoPi NEO was built using ARMbian build tools, then optimized and primed for DietPi.’ — so they simply ignored that Armbian considers all H5 based boards like NEO2 still being ‘work in progress’ and not ready to use. Therefore we at Armbian don’t provide any OS image for end users yet (will change once kernel 4.13 is out and we successfully optimized thermal settings).

    Also by installing a default Samba you miss a lot of important performance tweaks! Check your heatsink as already suggested and download FriendlyELEC’s OMV image for NEO 2. Way better choice than this DietPi thingie and containing all the OMV/Armbian optimizations for decent NAS performance since FriendlyELEC folks don’t suffer from ignorance.

  59. tkaiser
    July 30th, 2017 at 16:42 | #59

    doru :
    hardware: 2.5″ hdd, Western Digital 320 GB with file system NTFS, one partition

    Overseen before: https://en.wikipedia.org/wiki/NTFS-3G#Performance

    Using ntfs-3g on slow ARM devices is a great idea to lower performance and massively increase CPU load for no reason 🙂 You should better switch to ext4 or btrfs instead.

  60. July 30th, 2017 at 18:07 | #60

    @tkaiser
    That was true 10 to 5 years ago, now ARM processors are quite fast, so in most cases there are no big differences between NTFS and EXT-4 sequential performance in recent hardware, at least when using (mechanical) hard drives. It’s quite possible CPU usage is still higher though. I have not checked this for a long time.

  61. tkaiser
    July 30th, 2017 at 20:48 | #61

    @cnxsoft
    Hmm… since I was investigating USB3 issues with ROCK64 I simply gave it a try. Benchmark calls used:

    Results: https://pastebin.com/ruP3PRR1

    Obviously with ntfs-3g/FUSE iozone’s -I parameter got ignored: -I –> Use DIRECT IO if possible for all file operations. Tells the filesystem that all operations to the file are to bypass the buffer cache and go directly to disk. (not available on all platforms)

    So I repeated part of the test with 12GB file size (ROCK64 unfortunately has 4GB DRAM and I wanted to use at least 3 times the physical RAM to fight a little bit the aggressive buffering/caching with NTFS). So with huge block sizes we’re talking about 380MB/s possible with ext4 and only ~140MB/s keeping in mind that iozone in this mode fails to report real NTFS performance due to FUSE/ntfs-3g caching effects — all read values for NTFS are way lower in reality or if more suitable benchmarks were used for this use case.

    Sequential reads with small block sizes (4K) look like this wrt CPU utilization (30 second samples and then averaged):

    When we subtract the %iowait percentage for ext4 we end up with a difference of 94% idle vs. 71% with ntfs-3g. Also important: I tested on a quad core A53 running at 1.3GHz. With ntfs-3g the worker thread was all the time at around 90% CPU utilization almost fully using one CPU core. On something like NanoPi NEO 2 which is only allowed to clock up to 864 MHz reliably this will already bottleneck IO performance with ntfs-3g especially when using a crappy distro that doesn’t give a sh*t about necessary performance tweaks (eg. IRQ affinity to prevent all interrupts being processed on cpu0 which will lead to a nice overall performance drop in NAS situations when both network and storage are busy).

  62. doru
    August 1st, 2017 at 01:16 | #62

    @cnxsoft
    Thanks for the sugestions. I’m pretty sure that thermal pad and heatsink are properly installed but I will ckeck to avoid any doubt. Seems is software problem like ‘tkaiser’ told in comment 58.

  63. tkaiser
    August 1st, 2017 at 01:22 | #63

    @doru
    Tried NAS performance with Samba today and compared between DietPi and OMV on a Raspberry Pi 3 and an ODROID-XU4 (but simply broke testing since DietPi’s NAS ‘performance’ was too disastrous): https://forum.openmediavault.org/index.php/Thread/18991-New-approach-for-Raspberry-Pi-OMV-images/?postID=150444#post150444

  64. doru
    August 1st, 2017 at 01:30 | #64

    @tkaiser

    You are right. Seems to be a software choice problem. Using Dietpi and proftp server I tried to copy the same big file (2.2GB) through FTP client. I removed the HDD because I’m afraid to damage due to whole system temperature. This time I used a SanDisk USB 3.0 stick, Ultra Fit 32 GB more exactly. After the 25% of the file was transfered the system frozen and I think was reseted. I will switch to FriendlyARM OMV image and I will post some data about transfer speed and temperature. Thanks for your informations.

  65. doru
    August 2nd, 2017 at 02:48 | #65

    tkaiser :
    @doru
    Tried NAS performance with Samba today and compared between DietPi and OMV on a Raspberry Pi 3 ….

    Well, it is obviously now for me that was not the right choice when I chose Dietpi distro, but for ordinary user like me, when I tried to find simple but reliable solution for my needs this two points determined my choice:

    1. simplicity – I have a SBC and I want to use with OpenVPN to connect to my home network and later I want to add Pihole to block some ads
    2. reliability – at the time when I chose Dietpi distro I found a lot of people complains about SD card failure and Dietpi had included the method and guide to move all data from SD card to USB stick. This makes the whole system less liable to failure.

    In few words: I have a Raspberry Pi board, I found on search engines Dietpi distro which have both OpenVPN and Pihole software installation option and they have on their forum step by step method to install the software and move the root file system to USB stick keeping the SD card just for system boot.

    That two facts determined me to made my choice. However, that two concepts, simplicity and reliability, are very relative, even for the same person. What was reliable for me at the time when I made the choice, now seems aren’t because I know, thanks to your posts, the problem with Nanopi Neo 2 and Dietpi distro combination is not about just SD card failure but OS and software optimization.

    After I finished my little project with OpenVPN and Pihole on Raspberry Pi I tried to use my other board, Nanopi Neo 2 with 1-Bay NAS for backed up my data but as I said and you had confirmed, that combination, Nanopi Neo 2 with Dietpi are unusable right now due to bad software implementation.

    Definitely I will switch on Nanopi Neo 2 board, from Dietpi, to OMV FriendlyARM image. My concerns are about SD card speed and corruption and I think to try keeping the SD card just for system boot and using an USB stick for system files but I don’t know how to do that with OMV FriendlyARM system.

    Maybe, you have some advices for me, please?

    In my opinion fewer software are better. For example I think just armbian with samba software would be the best combination but is more advanced project for me.

    Thanks

  66. tkaiser
    August 2nd, 2017 at 13:17 | #66

    @doru
    SD card issues are very common everywhere but there exist a few steps you can do prior to usage (do a web search for ‘armbian getting started’ to read through online docs where this is outlined in detail). Especially Raspberries were plagued by SD card crappiness since on first generation Raspberries further SD card issues were created while operating the boards due to a shitty power design. This has been fixed with 2nd generation Raspberries a few years ago (A+, B+) but once a myth is on the Internet the story will be told over and over again.

    If you buy good and genuine SD cards (check the search field here on CNX in the upper right and search for ‘micro sd’ to read through a very good compilation of ressources) there’s nothing wrong running off an SD card. Some distros keep log files and other frequent changing stuff in memory and sync it to storage only once an hour (Armbian, DietPi and official OMV images for example) so if you ruled out ‘initial SD card troubles’ (buying counterfeit cards, burning the OS image wrong by avoiding Etcher) you also don’t have to fear early wear out of the card later.

    Moving an installation from a good and genuine SD card to a crappy USB stick is stupid of course. All flash media can be crappy and should be handled the same way: Directly tested after purchase. I did this recently with a bunch of cheap USB sticks that were lying around here and there: the majority of them was magnitudes slower than a good Samsung EVO+ with 32GB for example and three went directly to the trash since showing errors. Moving an OS to such a crappy device is moronic.

    The official OMV for ARM images since based on Armbian contain the nand-sata-install script (historically named wrong but Armbian core team unfortunately doesn’t care about such stuff, same with Armbian’s self-promotion) so you could move your installation away from SD card to eMMC, NAND, USB or SATA storage just like you wish. But to be honest: Since good SD cards are not really more expensive than crappy SD cards I simply buy the first category only. On all of the ARM servers we run at customers OS installation remained on SD card or eMMC and we’re using btrfs with compression and regular scrubs to check for data integrity issues. So far none occured.

    • doru
      August 2nd, 2017 at 13:49 | #67

      Thanks for your detailed explanations. I will search for more informations related to armbian and I will try to begin switching from DietPi to armbian my RaspberryPi-OpenVPN-Pihole project. For my back-up project using NanoPi Neo 2 and 1-Bay NAS I will use FriendlyARM OMV image with good SD card following your advice. Thanks for that, and not last, for your time.

  1. No trackbacks yet.