OMV vs NAS4FREE / FreeNAS "dedicated-diskless" installation

  • Hi,
    after a lot of searching I choose OMV for my NAS project (just started putting hardware/devices together).
    From a (linux/nas) newbie point of view I wonder if it's true that NAS4FREE and FreeNAS differently from OMV don't require a dedicated drive for the system to install into and, If so, the reason of that choice.


    I may think that the OS loads into the ram and, since in most of the cases the machine is supposed to be always on, the "system" drive is just needed for a reboot and/or a change of the settings.. if I'm right. If so it seems like this solution to be more fault proof because no extra drive required (but I may also understand that in most of home scenarios we don't need our nas on 24/7 and probably the OMV solution helps in preserving the settings).


    I know I'm probably missing some knowledge or misunderstanding a couple of things, thanks for any explanation or help in making me the picture a bit clearer.
    Beside that, as already said, I already choose OMV: I'm more keen in running a Gnu/Linux system and looking forward for the BTRFS support (any news relating the road map?).


    Thanks for your help/work!

  • The OS disk is written heavily to, not just by debian itself but by all the constant logging that is done and various other things. Thus, only a dedicated drive is possible. Also, Debian does not load itself to the RAM like you think... and I'm curious if FreeNAS does that either...


    Oh, and because of that constant writing USB sticks (without wesr leveling) are a no-go.


    Greetings
    David

    "Well... lately this forum has become support for everything except omv" [...] "And is like someone is banning Google from their browsers"


    Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.

    Upload Logfile via WebGUI/CLI
    #openmediavault on freenode IRC | German & English | GMT+1
    Absolutely no Support via PM!

  • I may think that the OS loads into the ram and, since in most of the cases the machine is supposed to be always on, the "system" drive is just needed for a reboot and/or a change of the settings..


    That is NOT correct! Debian and OMV reads and writes almost constantly to the drive.


    if I'm right. If so it seems like this solution to be more fault proof because no extra drive required (but I may also understand that in most of home scenarios we don't need our nas on 24/7 and probably the OMV solution helps in preserving the settings).


    Absolutely right. If the system drive is damaged, you just need to install on a new drive and mount your data drives to have all your data back.

  • Why not using an wear levling Support Linux FS like "YAFFS" etc. for the USB drive ?


    Or is this not support in the installer ?


    I used this file system on some of my Live Sticks and they work since years without falling apart.


    But 24/7 might be another story .


    any thouts on that ?


    kind regards

    • Offizieller Beitrag

    Looks very interesting. What OS are you using? yaffs2 isn't part of Debian.


    Also found this comment:


    Zitat

    In practice, flash file systems are only used for memory technology devices (MTDs), which are embedded flash memories that do not have a controller. Removable flash memory cards and USB flash drives have built-in controllers to perform wear leveling and error correction so use of a specific flash file system does not add any benefit.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


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


    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!

    Einmal editiert, zuletzt von ryecoaaron ()

    • Offizieller Beitrag

    I figured you used Gentoo :) Used it a long time my self.


    Debian doesn't have ubifs or yaffs2.


    That is what I found. Even the ubifs page itself say the following:


    Zitat

    One thing people have to understand when dealing with UBIFS is that UBIFS is very different to any traditional file system - it does not work on top of block devices (like hard drives, MMC/SD cards, USB flash drives, SSDs, etc). UBIFS was designed to work on top of raw flash, which has nothing to do with block devices. This is why UBIFS does not work on MMC cards and the like - they look like block devices to the outside world because they implement FTL (Flash Translation Layer) support in hardware, which simply speaking emulates a block device on top of the built-in raw flash. Please, make sure you understand the differences between raw flash and, say, MMC flash before dealing with UBIFS.


    Unfortunately, the same applies to yaffs2.

    omv 7.0.5-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.1.4 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.4


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


    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!

  • I don't think it's a huge deal OMV requires a hdd, but I can see how many would. There are tutorials for making a system run from RAM persistently, a ton of them in fact now that all flash based distros have that option, so no biggie. I already tried this, but being I'm back to 2gB of RAM, I noticed an increase of CPU usage/heat (even with NAS4free, but I'm running par2 on the server).


    That being said, I think systems like embedded NAS4Free are doing this particular aspect right, but in other aspects OMV is at least as good as the rest in the audience of NAS, not worse.


    Again, I don't care about embedded, but I don't see a problem with OMV making this an option. Or at least supplying limited support for working log/conf directories to help the usage of embedded with OMV.


    I will say this 1 thing defiantely negative about OMV, the constant disk access for all things really needs to be cut back (for heat's sake alone). I only care about failures, not successes.


    All in all, I'm EXTREMELY happy with OMV! I know first hand that "Hell is other broswers", and even if the days of client hacks are gone, it still takes time to put all that js/css together (although I question the login form... why that?).


    Anyways, thank you OMV devs and help supporters. GNU maybe, but time isn't FREE!

  • What do you think is wrong with the login form?


    Greetings
    David

    "Well... lately this forum has become support for everything except omv" [...] "And is like someone is banning Google from their browsers"


    Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.

    Upload Logfile via WebGUI/CLI
    #openmediavault on freenode IRC | German & English | GMT+1
    Absolutely no Support via PM!

  • Looks nice, allthough it misses the part to write back to the HDD in case of changes/shutdown/reboot.


    Greetings
    David

    "Well... lately this forum has become support for everything except omv" [...] "And is like someone is banning Google from their browsers"


    Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.

    Upload Logfile via WebGUI/CLI
    #openmediavault on freenode IRC | German & English | GMT+1
    Absolutely no Support via PM!

Jetzt mitmachen!

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