[Tutorial][Experimental][Third-party Plugin available]Reducing OMV's disk writes, also to install it on USB flash

  • Great stuff, thanks.


    I have just commented the 3 USB lines and will reboot once the raid sync will be done.
    It's very suspicious anyway that sda1 was the main SD partition where OMV was installed, sda2 was the extended partition containing sda5 which was instead the swap partition.


    Just to confirm, if I add any USB device, these will be recongnized/mounted via the "File System" tab and would perhaps be listed as sdh/sdj/sdk, correct?


    Thanks,
    Tommy

    HP MicroServer Gen 8
    HP DL360e Gen 8 + HP StorageWorks D2700

    HP DL380e Gen 8 + HP StorageWorks D2600

  • Zitat

    Just to avoid to have much RAM allocated for logs and files which are not needed.

    Most of the writing is inside rrd databases (database of fixed size, each new line deletes the oldest line) and pre-calculated images to display graphs in the interface. Plus a bunch of logs and text files that don't change a whole lot. It's not really growing, the same files are read-erased-updated-written over and over again.
    The actual amount of data is somewhere around 30 mb. Changes often, so if the controller of the flash memory sucks and cannot do wear-leveling the flash cell where that data sits dies fast, if the controller can do wear leveling... it's still a ridiculous amount of writes, so the flash device will last longer but not really that much overall.


    The solution was obviously moving the offending folders to RAM, where all this write activity is not an issue.


    Zitat

    given the Swap partition has been commented out, is it suggested to
    actually remove the partition from the drive and completely remove the
    entry from the fstab?

    If the SD has a half-decent controller, the wear-leveling will not care about partitons. If it does not have a half-decent controller, its wear leveling will suck in any case.
    I'd say it is unnecessary to remove it, unless you really need the space anyway.


    The standard Raspbian image doesn't use swap and neither does my odroid-c1 image.

    Afaik raspbian uses dphys-swapfile in its standard image (i.e. it generates a swapfile). You mean you removed it from your OMV-raspberry image?


    the odroid has 1 GB I think, so it is probably fine.


    Zitat

    The kernel still knows what to do when it runs out of ram and/or swap
    space.

    apart from reclaiming ram by purging caches, that's generally done by terminating programs. OOM Killer terminates the least important process that will free the most ram.
    This means on average that whatever program you were running gets axed if the device runs out of RAM.
    Personally, I've never had problems with embedded devices with 512mb of RAM or more, but I always keep a swapfile handy just in case. With 256mb a swapfile is useful.


    Anyway, did you try automating the fstab modifications?
    with this you should be able to automate it within the script, so the user does not need to go and SSH and do things manually.

    Code
    awk '$2~"^/$"{$4="XXX,XXX,"$4}1' OFS="\t" /etc/fstab


    Instead of XXX place the options you want to add.


    For the swap this

    Code
    sed -i.bak '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab


    Assuming that you run the script as root.


    Fast troubleshooting info (would be nice to integrate this in a watchdog script so the plugin can fix itself without user intervention):
    Ran some tests in a VM, the only time when the system is vulnerable is at shutdown, when fs2ram is updating its files on disk.
    If there is a power loss or if fs2ram is blocked somehow in that situation (say a user that is too eager to power off the NAS and pulls the plug), the files it was writing might not be complete or readable. So it is possible that on reboot the OMV's web interface will refuse to start due to not finding its folder structure.
    This is more likely to happen on ARM devices due to weaker processors that will take more time to do this updating. On a x86 cpu it's pretty hard to get into this situation.
    It's not a particularly worrying scenario, fs2ram is not working with critical data so the system is fine, it's just OMV's web interface that freaks out and crashes if it does not find its folders.
    The folder structure on disk is still there and correct (fs2ram does its own things without changing the actual stuff on disk), we only need to disable fs2ram temporarily to get the web interface back.
    In this case SSH to the NAS (or connect a screen and a keyboard), log in and then run a

    Code
    sudo rm /etc/init.d/fs2ram


    This will delete the startup script of fs2ram.
    then write

    Code
    sudo reboot

    to reboot.
    On reboot the web interface should be back, now uninstall and then install the flashmemory plugin to fix any issue.


    depending on the exact issue, it's possible that if you write sudo fs2ram unmount -a -f followed by a sudo fs2ram mount -a -f you should fix the issue too, but with the above procedure it's more general and works for sure in any case.

    • Offizieller Beitrag

    Afaik raspbian uses dphys-swapfile in its standard image (i.e. it generates a swapfile). You mean you removed it from your OMV-raspberry image? the odroid has 1 GB I think, so it is probably fine.


    Nope, I didn't remove it. Never noticed it was installed. So, I guess the RPi image does use swap if needed. The odroid image does not use it.



    Anyway, did you try automating the fstab modifications? with this you should be able to automate it within the script, so the user does not need to go and SSH and do things manually.


    I had the code in the plugin at one point but I took it out. Altering fstab is just too dangerous in my opinion. There are just too many different fstabs out there especially looking at the arm images. You never know if the root drive is mounted by drive letter or uuid or whatever. Leaving swap in the fstab isn't bad if the system doesn't use it. The instructions in the plugin are very verbose and easy enough that a noob could change things.


    Personally, I don't want to add code to the plugin to watch for a user unplugging the board while it is shutting down. I like it simple and it is working very well on my four systems. I even want to remove the enable checkbox.

    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!

  • Zitat

    Altering fstab is just too dangerous in my opinion.

    An easy way out would be to make a disk image ready to be installed in a USB drive or SD/microSD for a x86-64 NAS.
    Since we are not dealing with proprietary drivers or machine-specific configurations, it should work fine anywhere the hardware is supported by the kernel.


    Using a pre-made USB image is also easier than installing with a DVD, as it is just:
    -download the IMG file and unzip it (also this makes sure that the file isn't corrupted)
    -flash to USB with a tool like this or whatever http://www.askvg.com/win32-dis…-to-usb-drive-in-windows/
    -plug it in the NAS
    -boot from it
    -????
    -profit


    Zitat

    There are just too many different fstabs out there especially looking at the arm images. You never know if the root drive is mounted by drive letter or uuid or whatever.

    For the scripting route I can help. A mildly smart script using the all-powerful awk can easily do the job at hand.
    The root is always the one with \ in the second field.
    The same for swap, it's clearly labeled as swap in second and third fields, it's hard to miss.
    I whipped together this, and tested it in various conditions (with a bunch of text files).
    If I was more pro, I would have used functions and other tricks to make it short, cool, and nearly impossible to read for any non-pro.
    While less than optimal it does the job and should be easy to understand. I heavily commented it to ease the understanding and mainteneance.
    Since it is a proof of concept, safeties and sanity checks were not a priority so many input and output checks were not implemented. Can add safeties later if you like it.
    Feel free to test it yourself (change the name/path of the /etc/fstab to the path to a copy of the fstab you made inside your home folder or whatever, so you can test it safely).
    Since it relies on awk to work, it should run anywhere, as awk is in both debian proper and in the Busybox installed in ARM devices (if they don't have the full Debian infrastructure anyway).


    Zitat

    The instructions in the plugin are very verbose and easy enough that a noob could change things.

    I understand, but the entire point of OMV and its plugins is to avoid having to use terminal and SSH, doing it automagically is better imho.
    I can offer some assistence for scripting as you see above.


    Zitat

    Personally, I don't want to add code to the plugin to watch for a user unplugging the board while it is shutting down.

    No, that would be too complex. The code should run at boot and detect if fs2ram ran without errors during boot, if it finds errors then it triggers the procedure to auto-fix the issue.


    It's still somewhat complex though, may be better to not add nothing until an elegant solution is found.


    Zitat

    I even want to remove the enable checkbox.

    Would agree with the idea, but what if someone downloads dozens of plugins at once?
    When installing this one it may screw up the installation of others as it logs off and runs fs2ram.
    If this potential issue can be solved, then I'd say go for it.

  • My suggestion would be to contact Volker wether or not he is willing to integrate this into the core, which would take care of all requests for usb installations one for all. Allthough I remember him denying it back then due to the possibility of people not having a UPS which then could get logfile inconsistency.


    @votdev: Volker, Your turn.


    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!

  • My suggestion would be to contact Volker wether or not he is willing to integrate this into the core, which would take care of all requests for usb installations one for all.

    I agree. Just a minor clarification though: in all fairness, this is a third-party hack relying on fs2ram, integrating this is not elegant if you have access to the source (as pointed out by HK-47 it's just a matter of defining folders somewhere else).


    If Volker agrees to make a more flash-drive-friendly OMV we can find better, more stable and elegant ways to make it happen (fs2ram is in Unstable, and isn't exactly perfect in many respects, it certainly does the job, but we can do better for this project if he agrees).


    Like placing all this stuff (logs, rrd, graphs and whatnot) in a OMV dedicated folder inside of the standard tmpfs folders for Debian (like /run/shm ) and using a cron/anacron job to sync the stuff to a system-reserved folder in data drives by default (plus a Init script that clones the contents to ram at reboot).


    Leaving settings to let the user decide the sync interval when the disks are sleeping, while when the disks are active everything is synched real-time or so. (the logic behind this is that if disks are inactive the NAS is probably doing nothing, so logs of those times are less important, while if disks are already active there is no issue at adding a few dozen mb on top)


    This syncing would work for ALL data drives and RAID volumes independently, so any drive or raid volume would have its own system-reserved folder with this logging inside.
    So when for example drive A is active while drive B is sleeping, the logging is synched real-time only to A. If drive A goes to sleep and drive B becomes active, syncing will be done to drive B.
    After all we are talking of 100Mb max, and that's not going to impact the drive space for any half-serious hard drive or raid volume.
    Since we'll be using rsync or something serious like it to do the syncing, this logging can even be sent to another system, in realtime (if properly set up with the web interface anyway).


    I should be able to do some scripting to make this happen, i'm not just a noob with a dream. :)


    Imho it isn't nice to force everyone to use a SSD or a HDD and a Sata port for the NAS's own OS mainly because of logging consistency, much can be done to preserve logs even with the OS on a flash USB/SSD.
    But I respect his choices anyway, he is the dev, OMV is his project.


    p.s. if you think he will have troubles understanding the proposal due to language barrier, feel free to translate it in german. I can't do it. :)

  • Please help me understand something.
    I've been using this plugin for more than a month now without rebooting, and i was worried that it might fill my memory. Doing free shows me this:

    Code
    total       used       free     shared    buffers     cached
    Mem:       3930108    3773872     156236          0     165084    2370016
    -/+ buffers/cache:    1238772    2691336
    Swap:      1233916        144    1233772


    But df -h tells me that the tmpfs partitions are about 99% empty, the most used is /var/cache with about 6% utilisation. So do i need to worry about memory usage or not? Does this plugin need a periodic reboot to keep memory from filling up?


    Thanks.

    • Offizieller Beitrag

    @bobafetthotmail


    I agree with the dd image. It has worked well for the RPi and odroid. Grub might be the only issue.


    Thanks for the script but like I said, I had that part written but didn't trust it. While I agree root is always the entry with the / in the second field, what if the user has /var mounted on a different partition? Setting noatime/nodiratime on root won't help then. Stuff like this is why I prefer leaving the changes to the user even if goes against the idea of doing everything in the web interface.


    It would easier in my opinion to create an fstab tab in the plugin. In that tab, we would show the actual fstab and the proposed fstab. The user could make changes and save it.


    I don't like the idea of setting a write back interval. This defeats the purpose of the plugin to eliminate as many writes as possible. Even if it is on 30-60 MB per day, that is doubling the writes that my systems are currently seeing.


    As for the checkbox, fs2ram when installed unattended, creates a basic config and starts. I didn't prevent the starting in the plugin. I will do some testing to see if installing it with a group of plugins will cause issues.


    I guess in the end, I still like keeping the plugin simple. I have had no issues and haven't head of any issues with it :)

    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!

  • Please help me understand something.
    I've been using this plugin for more than a month now without rebooting, and i was worried that it might fill my memory. Doing free shows me this:

    for a linux system it is normal that the "free" ram is low.
    The misconception is pretty common for newbies, see here for details. http://www.linuxatemyram.com/


    The short version is look at the -/+ buffers/cache: line. It shows 2691336 as free. That's around 2.7 GB of cached stuff from the system that can be freely purged if something more important needs moar ram.
    tmpfs isn't purgeable, so it is not calculated inside that number.


    Zitat

    But df -h tells me that the tmpfs partitions are about 99% empty, the most used is /var/cache with about 6% utilisation.

    df -h should tell you the size of the stuff in each tmpfs folder in the Used field.
    That's the space physically occupied in RAM by the stuff in that folder. The Avail field is a maximum size, there only for safety (so that even in worst case scenario where a bug or something hits you, the tmpfs won't fill up the RAM and crash the system).


    Given that by default the tmpfs is limited to half your ram, if you are using 6% of half of your ram, that's somewhere around 100 MB.


    Since /var/cache contains the folder where update packages are downloaded and kept before being installed and little else, I suspect that most of that is just packages left over from when you updated OMV.
    those packages can be freely purged by writing

    Code
    sudo apt-get clean

    (if you are already the root user you don't need to write sudo) Then check again its space utilization.
    I thought the plugin was auto-purging that folder on its own though. I did warn about that in the OP.

  • Grub might be the only issue.

    Wat? As long as Grub is booting partitions inside the same drive as the MBR there should be no issues.
    I have some experience in installing full linux desktop OS inside a drive and then moving the drive to another PC (common to sidestep the fact that the kernel is too old to run the newest devices on most dristros, AND that the only way to install the damn thing is through a graphical interface that without recognizing the GPU does not really work that well) or running them from USB (external hard drives).


    Zitat

    Thanks for the script but like I said, I had that part written but didn't trust it.

    Since you first said "You never know if the root drive is mounted by drive letter or uuid or whatever.".
    I'm inclined to agree, the part you wrote was not likely to be really trustworthy.
    Does not mean that all scripts aren't trustworty though, only that you need to improve your skills or ask for assistence.
    There is no shame in asking for assistence if the idea you are pursuing is indeed good.
    This also provides the propulsion to learn and improve your skills, which is always a good thing.


    Zitat

    what if the user has /var mounted on a different partition?

    Shifting goalposts will cause anger and frustration in those trying to help you, it is advised to state your full requirements in detail as soon as possible.


    As to the answer to your question, see the following script, it is heavily commented for the sake of easy understanding and mainteneance.
    Being a proof of concept, no safeties are included. Test it the same way I explained in the post above.
    Also took the chance to make it slightly less clunky than the first iteration above, you know, helps giving the impression of the work of a pro.


    Zitat

    It would easier in my opinion to create an fstab tab in the plugin. In that tab, we would show the actual fstab and the proposed fstab. The user could make changes and save it.

    asking a noob to open up the fstab and make modifications is not a very safe thing to do, even if you make it in the webinterface.
    They can get disoriented by a file they never saw before or make typos.
    Any error in fstab can be critical as it can prevent the OS from booting, and you don't really want that.


    Zitat

    I don't like the idea of setting a write back interval.

    That was an advanced thing using folders in the data drives/volumes, that won't be flash-based I hope.
    It's complex even for me, so it's probably well above your own scripting skills, and most users can live without anyway.


    Zitat

    I guess in the end, I still like keeping the plugin simple. I have had no issues and haven't head of any issues with it :)

    You should judge the simplicity of the plugin when you look at it with the eyes of a noob user, not with the eyes of the coder writing it.


    Your plugin is NOT simple for a noob user, period.
    While it is indeed simple for you, the coder.


    In general, simplifying the complexity so that even a noob can operate it is seen as a big accomplishment, publishing half-baked code that requires manual intervention and complex explanations... not that much.
    Also because frankly, programming is all about automating stuff, using a few more hours now to save millions of hours later, to many people too.


    See here for details about general rules of thumbs to follow when making a piece of code http://www.royvanrijn.com/blog…aits-of-good-programmers/

  • I don't think a complete noob user should use OMV. A complete noob will buy a Synology (or a Thecus first and then realise they needed a Synology) and be done with it. I guess when you installed OMV you can follow some commands...

    • Offizieller Beitrag


    Obviously, my 33 years of programming experience are worthless and I have no idea how to program or make a plugin. I'm done with this plugin. If you want it done "right", you can fix it...

    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!

  • Obviously, my 33 years of programming experience are worthless and I have no idea how to program or make a plugin.

    I have been too harsh and made assumptions about your skills after looking at a too limited data set, I apologize.


    I'm very angry at people that make half-baked crap at my job (crap that I need to hack and fix, losing time I would love to use to do something more useful for the customer), some of that did vent on you.
    Again, I apologize.


    Zitat

    I'm done with this plugin. If you want it done "right", you can fix it...

    What about teamwork? I script (also for other plugins you might want some help with, in return for your aid with this one that I do care a lot about), you make the plugin.
    We can rule this galaxy together, in peace.


    Zitat von Meniak

    I don't think a complete noob user should use OMV.

    I guess you never read what it says on the tin.
    http://www.openmediavault.org/about.html
    OpenMediaVault is primarily designed to be used in home environments or
    small home offices, but is not limited to those scenarios. It is a
    simple and easy to use out-of-the-box solution that will allow everyone
    to install and administrate a Network Attached Storage without deeper
    knowledge
    .


    Zitat

    I guess when you installed OMV you can follow some commands...

    I know, but it is a slippery slope.
    A little bit of "following commands" here, a little bit there and it becomes a pain to use, and an even greater pain to maintain.
    And people will start wondering why there is a webinterface at all.

    • Offizieller Beitrag

    Volker informed me that non-rotational media should have noatime, nodiratime, and discard set when installing OMV - see code. While it doesn't seem to working on all non-rotational media (my samsung ssd included - bug report), that should eliminate the need to add that to the plugin. If you installed from Debian (not OMV ISO), then you can manually modify fstab because you are not a noob.


    I also filed a feature request to use the dphys-swapfile package which would eliminate the need to change that line.

    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!

  • Hmm... even from manual install I need to run omv-initsystem at the end, so that script should run in any case, manual or ISO.
    Did it change lately?
    No, stupid question, all logged.
    Last change in 03-03-2014.


    So, the flash drives I used when testing (and now) aren't getting properly recognized as non-rotational.
    Or maybe I did something stupid...


    Kernel issue or me doing something stupid... hmm... probably the latter but for the sake of fairness, I'm going to check. :D


    For now, the suspect about kernel issues is rising.
    https://bugzilla.redhat.com/show_bug.cgi?id=1113777
    https://bugs.launchpad.net/linux/+bug/499237


    I
    believe this is called displaced aggression... hehe

    He who is without sin can cast the first stone.
    I remember a couple of your posts from page 2 and 3 that would also qualify. HK-47 also commented on that.

    • Offizieller Beitrag

    The script didn't recognize my Samsung 840 ssd either without creating a new udev rule. Volker added my rule to the preinstalled udev rules but that won't fix all the other drives not recognized as non-rotational.

    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!

  • Because the script relies on the kernel to detect the device as rotational or non-rotational, and applies the mount option change change ONLY on devices that are non-rotational (apart from hacks like that udevd rule you both made for your devices of course)


    with

    Code
    cat /sys/block/sda/queue/rotational

    you see 0 or 1. for flash it should be 0.


    There are some bug reports around, and both you and Volker seem to have found two devices where it screws up. It looks like a kernel bug.


    https://bugzilla.redhat.com/show_bug.cgi?id=1113777
    https://bugs.launchpad.net/linux/+bug/499237


    I still have to go home and check my own stuff, but I'm starting to suspect that this rotational detection is a bit unreliable.

Jetzt mitmachen!

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