Raspberry Pi - Why?

  • Why would anybody even have a need for OMV on Raspberry Pi?
    It only has USB 2
    It's onboard NIC is only 100mbps
    You can only get 300mbps using a Gigabit NIC thanks to the USB2 limitations.
    I imagine even the AC wifi is limited to about the same throughput.
    Your only full speed storage option is an microSD card, which at it's best is slower than a platter.


    So again....Why?


    I would seriously pull my hair out if I had to wait for 300 megabits per second transfers. Remember HDD/SSD and SD are all rated in Mega Bytes per Second. Each Byte is 8 bits.


    I am one who appreciates other point of views, so this is simply a curiosity question and not meant to insult anyone. I am looking to learn what I am missing?


    This stuff struggles on an i7 when it comes to OS loading, which is the main reason for my curiosity. Of course I enabled ZFS and burn up 13GB of RAM while transferring, so this further puzzles me that a 1GB device could work at all. I don't run linux on 1GB even in a vmware environment. It can be done stripped down...but OMV is not what I'd call stripped down. Every store bought NAS I've ever touched was a complete let down, and they seem to have similar specs as a Pi3B.

  • Why would anybody even have a need for OMV on Raspberry Pi?


    Since the average RPi user is rather clueless and has been told (by 'the Internet' or 'the media') that a RPi would make up for a great energy efficient NAS. The opposite is true (it's the worst choice possible for everything involving network and/or storage) but this doesn't change the fact that RPi users want to use these lousy things as NAS. So we prepare an own image (my hope was that this image helps to demonstrate some of the more 'famous' RPi problems like underpowering) but so far to no avail.


    If people use an RPi for a NAS, ignorance seems to be the main ingredient. Though we try to educate users somewhat, e.g. Which energy efficient ARM platform to choose?


    Every store bought NAS I've ever touched was a complete let down, and they seem to have similar specs as a Pi3B


    I don't know of a single NAS which would have as lousy specs as a RPi (the two main problems with the RPi are underpowering and SD card hassles -- inferior performance is something not that important). That said: Neither an i7 is needed for a performant NAS nor 12 GB of RAM. Good ARM boards work pretty well here. It's just the RPi that is a total fail.

  • OMV in a pi is a great form to introduce to the NAS world. I use one of theses at home. I tried things and learn how to configure things with OMV.


    Thanks to that, now I’m mounting a server just to learn about raid, and other things, and I use my Rasp, to download and movie server.


    I know that are another programs or OS to serve movies to my home but I’m happy whith it, and enought at the moment.


    Probably what the forum has to say about pi omv, that is for non production server or to learn.

  • Probably what the forum has to say about pi omv, that is for non production server or to learn.


    That's a great suggestion. Maybe an announcement thread could highlight all the shortcomings of using an RPi as NAS and then the readme.txt at the download location (the most ignored file there) should point directly as an introduction to this forum thread?

  • This stuff struggles on an i7 when it comes to OS loading, which is the main reason for my curiosity. Of course I enabled ZFS and burn up 13GB of RAM while transferring, so this further puzzles me that a 1GB device could work at all. I don't run linux on 1GB even in a vmware environment. It can be done stripped down...but OMV is not what I'd call stripped down. Every store bought NAS I've ever touched was a complete let down, and they seem to have similar specs as a Pi3B.

    You must have high requirements for the NAS. I use Odroid HC1 with the old Exynos5422 and 2GB RAM without any problem. But I do not try to force it in a heavy enterprise environment.

    • Offizieller Beitrag

    Maybe an announcement thread could highlight all the shortcomings of using an RPi

    No one would read it just like all of the other announcement threads.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • You must have high requirements for the NAS


    I guess it's just defaults. ZFS default is to try to eat up as much RAM as possible for the ARC (a cache that is of close to zero use for home/SOHO NAS boxes) and by simply adjusting one or two tunables you get a ZFS NAS with just 1 GB RAM that is similarly fast as one with 128 GB RAM (for the home/SOHO use case -- if the ZFS shares host whole businesses like they do in most of our installations then it's an entirely different story).


    But yeah, I can understand that when users take a RPi, then examine the sh*tload of problems of these boards with the NAS use case, they generally think they would need an Intel box for something performant and reliable. At least that's my experience with customers. All those who played around with an RPi in the past were immune to any ARM proposals.

  • I guess it's just defaults. ZFS default is to try to eat up as much RAM as possible for the ARC (a cache that is of close to zero use for home/SOHO NAS boxes) and by simply adjusting one or two tunables you get a ZFS NAS with just 1 GB RAM that is similarly fast as one with 128 GB RAM (for the home/SOHO use case -- if the ZFS shares host whole businesses like they do in most of our installations then it's an entirely different story).


    But yeah, I can understand that when users take a RPi, then examine the sh*tload of problems of these boards with the NAS use case, they generally think they would need an Intel box for something performant and reliable. At least that's my experience with customers. All those who played around with an RPi in the past were immune to any ARM proposals.

    I do not have too much experience with ZFS but rather it seemed to me that ZFS and cheap sbc is not so popular target combination for soho.


    And RPi is simply a "cheap" multi-role sbc that I would not treat as a NAS ready. They just managed to create a brand that is the most popular and people.... will be people. :/

  • it seemed to me that ZFS and cheap sbc is not so popular target combination for soho


    While that's somewhat true I tried to address the 'I enabled ZFS and burn up 13GB of RAM while transferring, so this further puzzles me that a 1GB device could work at all' confusion.


    Every Unix/Linux system will take every bit of available RAM to make use of it. Since every other behavior would be foolish. If there's RAM, it will be used of course. If your system has 1 GB RAM this will take less time compared to a box with 128 GB. But of course all the RAM will be used and there's nothing wrong with it. Usually on systems with too much memory the majority of RAM will end up as filesystem/page cache -- when querying memory utilization with free this will be shown as buffers and caches.


    With ZFS it's the same (ZFS tries to assign RAM for the ARC cache which is close to useless in home installations since usually data that has been written will not be accessed immediately afterwards again) but on Linux you can't query the ZFS memory usage in the same way as with other filesystems where all these buffers/caches show up at another location. 'Fixing' this is as simple as doing a web search for 'zfs linux limit arc size' or something like that.


    ZFS memory requirements are not that huge unless you use deduplication. Only then you need to look at a specific formula to calculate the size of the DDT tables and then you can calculate how much RAM you need for which amount of ZFS storage. But if no dedup is used and ARC parameters are adjusted ZFS runs pretty fine on devices with 1 GB RAM or even less. But this doesn't mean anyone should use ZFS with a Raspberry Pi or a RPi at all if it's about NAS.

  • ZFS appears to use RAM to speed up the transfer process while maintaining some sort of resilience one would expect from a hardware RAID. Personally RAM is cheap compared to hardware RAID. For me I still have 50% overhead, so I wasn't complaining about that at all. Merely wondering what kind of job 1GB would do in comparison, I would guess that if I tried the performance would be similar to my My Cloud Mirror. In otherwords good for about 30 seconds and then begin deteriorating until the transfer is finished.


    I don't have high demands, just impatient. I was getting at the boot time in regards to CPU strength. Even before adding the ZFS plugin it took an unreasonably long amount of time to boot the system after BIOS POST. I kind of figure their is some code that could be cleaned up a little to improve the boot time. It's a first gen i7, I initially got the whole server for less than $200. I didn't go out and spend a fortune just to get CPU and RAM.


    I haven't had a single hiccup with the system yet, it even appears as the drives just sit idle when no transfers are occurring.

  • I was getting at the boot time in regards to CPU strength


    But that's pointless since usually boot time depends on hardware ingredients: amount of RAM, count of buses and count of stuff that hangs off these buses -- when you have several USB, PCIe, SATA or even RAID controllers then it will take time for the system to come up. Some time will be spent in 'BIOS' (be it the system's or the firmware of controllers) and then the kernel needs to probe every bus for peripherals that are attached to often doing stuff like speed negotiation in trial&error fashion.


    Both x86 and ARM devices can fully boot within less than 10 seconds if there's not that much attached to them and/or unneeded stuff is disabled. The RPi is neither x86 nor ARM but a VideoCore IV device which first has to load an own primary OS called ThreadX and can only then load a secondary OS like Linux/Debian/OMV so of course this adds to the amount of time needed to come up.


    Adding to that there can be software issues within the OS too. With recent Debian/OMV release checking the output of systemd-analyze blame can help identifying issues.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!