doru

This (and iozone output) looks more correct. But currently with 5.35 on sunxi hardware the CPU cores won't ramp up the clockspeed correctly (fix will be in 5.36 so simply do an 'apt upgrade' on monday) so for a new round of NAS tests (LanTest and Explorer) you might want to use the cpufreq-set call from above to switch from ondemand to performance to get an estimate how NAS performance will look like next week again.
 
 
I understood it this way and just wanted to warn that things might happen you don't expect. It's stuff people normally don't think about, it happens way too often and it's always fun to try to recover from such stuff.
 
For example encodings and umlauts: you create something with an Ä in its name on a file server, then attach the disk directly to the client. Still looks like Ä but different representation. So you can see the file but don't access it (there exist 4 different Unicode Normalization forms with 2 being used here and there). That's why I would refrain from trying such stuff. If data is on a NAS share then only access it there with the same daemon as when you created the data (eg. only using SMB/Samba or only using NFS or only using AFP/Netatalk when macOS clients are in the network)

at the time I started with armbian on the NanoPi NAS USBHost3 was loaded automatically.
So I activated Overlay 1&2. Not the USBHost0, because I doenst gave me additionally USB-Ports
 

Yesterday update was focused on stable builds only. 

Go to armbian-config -> system -> hardware configuration and enable USB ports on your own. Simple as that. If it doesn't work we need to look closely ...

I tested with an OMV image I created today for Hardkernel (so they can test their new eMMC themselves). OMV relying on btrfs as usual. Then tried out nand-sata-install twice and testing with ext4 and btrfs as target:
Ext4 target: contents of /boot are not copied, fstab wrong: bogus /boot and /media/mmcboot entries. After fixing both problems manually (rsync and vi) it works: http://sprunge.us/LTSX Btrfs target: rootfs is copied from mmcblk1p2 to sda1 but fstab is created wrong: /media/mmcboot entry gets UUID of old / (mmcblk1p2) instead of ext4 /boot (mmcblk1p1) and the bind mount is wrong too. After fixing the 1st problem manually (exchange UUID in fstab) it works: http://sprunge.us/hJFX In the 2nd case I think these are just two simple bugs (using $root_uuid instead of $sduuid and let /boot point to non-existent /media/mmcboot/boot) so I decided to fix them and limit the target fs choice when the current rootfs is already btrfs to also just btrfs (so no normal Armbian installation using an ext4 rootfs should be affected and those OMV images are condemned to stay with btrfs) .
 
Works now: http://sprunge.us/XIZX
 

It works !
 
By default just usbhost0, 2 and 3 are activated. (see usbhost1.png)
After I activated usbhost1 the USB port soldered on 1-bay NAS Dock
the storage inserted was recognized. (see OMV_physical_disks.png)
 
Thanks...
 
------------------------------------------------------------------
root@nanopineo2-nas:~# lsusb -t
/:  Bus 09.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
/:  Bus 08.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 480M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
-----------------------------------------------------------------------
 

without the case I got 35 degree while idle and 37 degree with the case
(dont know why - but I did lost my openshh-server installation - so I had to open the case and use the serial-TTL-port and did reinstall the openssh-server.)

Honestly I really don't trust that much into those internal readouts anyway. But back on topic, you're talking about a case responsible for lower temperatures now. But isn't the main difference now that your NEO2 is wearing FriendlyELEC's heatsink while it had no heatsink before?

In case that's different now I would be interested how temperatures look like without case.
 
 
I just worked on providing clean and performant OMV images for ARM boards relying on Armbian's Debian Jessie flavour [1] since almost all available OMV images I found were more or less horrible (using shitty kernels and crappy settings). Settings matter a lot on those slow ARM boards, if you choose the wrong ones (or rely on distros that 'optimize'/'tune' only irrelevant stuff like DietPi for example) NAS performance might drop drastically. And I posted the links above for a reason: since it's easy to get which settings are important by studying the respective install scripts.
 
[1] since when trying to install OMV on Ubuntu it can't work due to dependency mismatches -- that's why you find so many reports on the net of 'OMV does not work on Armbian' since people don't understand that it's either Debian or Ubuntu what they run.