New approach for Raspberry Pi OMV images

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • deluxecat wrote:

      what you can expect is 20 megabytes per second nas throughput (as tested with large files)
      So instead of wasting your time with a Raspberry Pi better look for any of the dirt cheap and far better alternatives that allow for almost 40 MB/s (or buy a slightly more expensive ARM board and then enjoy 'PC NAS performance' with a consumption not exceeding that of RPi + external network adapter that much. See this thread for details)

      deluxecat wrote:

      Working off my list, post 98, here's #2: SD speed. And its a 4-parter.
      I can't recommend following any of your points since
      1. Useless tweaks, the OMV image takes care of cpufreq governor settings in an appropriate way (/etc/defaults/cpufrequtils and /etc/init.d/armhwinfo do the job)
      2. 'hard drive cache tuning doesn't support SD cards'. So what? Data is on attached USB disks anyway?
      3. 'The default SD card reader speed is set on slowest' for a reason: Data corruption is nothing anyone wants and the main problem with SD cards is neither their sequential speed nor that access times are too high but that majority of people isn't aware that random IO is far more important for SD cards in computers and that there's a huge counterfeit problem with faked SD cards.
      4. 'Fstab options' -- you obvisouly missed that there's the flashmemory plugin active (fiddling around with /var/log in fstab is then a really bad thing). You're right wrt 'noatime,nodiratime,commit=600' but with flashmemory plugin it didn't make much of a difference (I checked it with 'armbianmonitor -d mmcblk0p2') so I chose to stay with Raspbian defaults since I didn't know whether any of the packages we get from messes with fstab
      5. NTFS is not recommended to be used with OMV (no POSIX filesystem so you run in a lot of hassles anyway, poor performance being one of the minor ones)

      For anyone being concerned about 'OMV performance' on his Raspberry Pi there is an excellent solution for this problem: Simply throw your Raspberry Pi away or do something different with it since it's the most lousy device for the job (due to its lack of decent networking and everything behind one single slow USB2 connection there). Better alternatives are countless and a lot of them cheaper anyway. Just choose the appropriate hardware, don't fiddle around with defaults and you're done.

      The post was edited 1 time, last by tkaiser ().

    • tkaiser wrote:

      So instead of wasting your time with a Raspberry Pi better look for any of the dirt cheap and far better alternatives that allow for almost 40 MB/s (or buy a slightly more expensive ARM board and then enjoy 'PC NAS performance' with a consumption not exceeding that of RPi + external network adapter that much. See this thread for details).
      Good info there! The gigabit equipped NanoPi Neo2 costs even less than a usb gigabit adapter, as well as doing NAS duties at least twice as fast as RPi3 (even 4x faster than a stock-condition RPi3).

      So, that means it is financially advisable to return the RPI3 to its mainstream use as an educational device. Although an exception could be some 150n, 300n, 100mbit networks that run near to the same pace as the RPi3. It also suits my use as a small web server.

      I especially liked your recommend of the Helios4, because that ECC memory could prevent accumulating holes in my photos and mp3 files. Also my i5 file server wastes most of its throughput on waking up; so, instead of a high wattage device that is asleep, I'd much rather have a low wattage device that is awake.

      As far as power-savers go, I've had a wishlist item for a long time: I'd love to have the hard drive scheduled to stay awake during work hours, but allow spindown at night. Is there such a thing as a Spindown Scheduler?
    • Wrt power savings... If your disk responds to hdparm parametrization (beware of crappy USB disk enclosures that prevent this) then I usually do this via crontab. One entry every evening allowing for short idle time (spindown after 10 min idle) and another one executed in the morning on workdays with eg. 240 minutes configured.
    • Quick compatibility announcement wrt next RPi model.

      We'll see rather soon a new RPi model (most probably not called RPi 4 but a somewhat extended 3 and Zero -- I expect the new SoC to both obsolete BCM2385 and BCM2387) with Gigabit Ethernet. Of course not real/fast Ethernet but USB2 attached (I would assume they take Microchip LAN7850) if Broadcom and the 'Foundation' choose to still rely on backwards compatibility and the horribly outdated VideoCore IV platform (most probably then with a die shrink to 28nm, replacing the Cortex-A53 with A35 to better cope with RPi 3 thermal and consumption constraints).

      Preparations for the new Ethernet chip happened already a while ago:…drivers/net/usb/lan78xx.c

      So maybe my latest OMV image for RPi will boot flawlessly on this new RPi model and can then be updated to latest versions of kernel and 'firmware'. But maybe an adjusted 'firmware' is necessary to boot this new SoC (of course it's not a firmware but a closed source RTOS called ThreadX that runs on the VC4 main CPU) and then someone would need to fiddle around with latest OMV image again though I would prefer to drop support for the RPi platform then since if it's still VideoCore IV then the 'single USB2 connection between SoC and outside' limitation still applies and NAS throughput will be still very limited (18 or maybe 19 MB/s since every bit has to pass the single USB2 connection twice!).
    • @tkaiser - thanks for the info and I hope all is well with you. Thanks to your advice/posts, I will not be buying a RPi 4!

      I'd like a little help for a new project for my RPi 3. I'm going to turn it into a VPN server as I have moved from London to Sydney and I need proper BBC iplayer, Netflix, Amazon Video etc.

      What I need is a nice clean base image/build. I was thinking about using the OMV image (from this post) but I think I just want the latest vanilla Armbian / Jessie. What would you suggest?

      The post was edited 1 time, last by jata1 ().

    • jata1 wrote:

      RPi 3. I'm going to turn it into a VPN server
      Worst idea possible. Better throw your RPi 3 away. Broadcom or the mythical RPi Foundation forgot to license ARMv8 crypto extensions so RPi 3 simply sucks at AES encryption/decryption:…findComment&comment=37829

      Better choose any other 64-bit ARM board you can get (except ODROID-C2 -- the other device that lacks ARMv8 crypto support) and configure your VPN to use AES. Will be magnitudes faster.
    • OK. Thanks but my internet ADSL is going to be slow anyway so it's still worth a try as an experiment.

      So how can I get a vanilla armbian install on my pi? Is there part of the script/tool/process that you used to created the OMV image that I could use?

      also... would my banana pi m2u (another bad purchase) be any good for VPN server?
    • Post#1 may have gone out of date, since Raspbian is currently linux 4.97, armv71, updates twice a week and all of the boards pictured don't have the cpu as the limiting factor. Might be good to have more customers and fair game to brief them on screen with their educational devices.
      Perhaps more importantly,
      I was also fascinated by an idea very much like luakit to localhost for showing OMV on the console screen.

      The post was edited 6 times, last by deluxecat: wordcount ().

    • deluxecat wrote:

      Post#1 may have gone out of date, since Raspbian is currently linux 4.97, armv71
      Just answering to this:

      Raspbian is a Debian based distro where all packages are built vor the ARMv6 architecture which isn't supported by Debian since 7 or even more years. This simple fact is the only reason why Raspbian exists: no Debian support for outdated CPU cores from 15 years ago (the ARM1136 inside the single core RPi SoCs is from 2002 -- as the name tells it's an ARM11 implementing ARMv6 microarchitecture) so all the gazillions of packages had to be recompiled for the RPi and that's all what Raspbian is about: recompiling and providing Debian packages for the outdated ARMv6 architecture.

      We switched with OMV to 'plain Debian' to get one single package base for all devices (minimizing support hassles). Since Debian supports only ARMv7 or ARMv8 (armhf and arm64 architectures) this doesn't work with the single core Raspberry Pi any more since their CPU core is an ARMv6.

      OMV for RPi uses the RPi foundation's kernel packages (the same that Raspbian uses), they provide one ARMV6 kernel and one ARMv7, the proprietary OS that runs on the VC4 detects the CPU type and then loads the correct kernel accordingly. And that's 4.9.79 currently though the kernel available through is usually some versions behind. So the same moment you get a kernel update with Raspbian you get the same kernel update with OMV too. There's no difference wrt kernel whatsoever

      One minor exception: we provide on the OMV image also a true but somewhat outdated ARMv8 kernel 4.11 but since this kernel receives no updates automagically it's not the default -- so it's up to adventurous users to play with this 64-bit kernel but there's no real reason since Raspberries are way too slow to be used as a good NAS and that's due to their lack of interfaces and not related to CPU cores or the kernel.

      The post was edited 1 time, last by tkaiser ().