Pinned [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
    • 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.

      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.

      ryecoaaron wrote:

      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.

      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.

      Source Code

      1. 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

      Source Code

      1. 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

      Source Code

      1. sudo rm /etc/init.d/fs2ram

      This will delete the startup script of fs2ram.
      then write

      Source Code

      1. 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.

      The post was edited 4 times, last by bobafetthotmail ().

    • bobafetthotmail wrote:

      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.

      bobafetthotmail wrote:


      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 4.1.13 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • 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 askvg.com/win32-disk-imager-wr…-to-usb-drive-in-windows/
      -plug it in the NAS
      -boot from it
      -????
      -profit

      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).

      Shell-Script

      1. #!/bin/bash
      2. #PREPARATIONS, backing up the fstab, just in case.
      3. cp /etc/fstab /tmp/fstab_backup
      4. #FIRST STAGE
      5. #here the script loads the mount options of root partition in a variable
      6. ROOT_OPTIONS=`awk '$2~"^/$" {a=$4;print a}' OFS="\t" /etc/fstab`
      7. #here the script checks if the root partition mount options have already a "noatime"
      8. if echo "$ROOT_OPTIONS" | grep -q "noatime";
      9. then
      10. #matched, cloning the fstab into a work file created in /tmp, this is needed by the second stage.
      11. cp /etc/fstab /tmp/tempfstab ;
      12. else
      13. #no match, rewriting fstab and writing the result in the work file created in /tmp, this is needed by the second stage.
      14. awk '$2~"^/$" {$4="noatime,"$4}1' OFS="\t" /etc/fstab >> /tmp/tempfstab;
      15. fi
      16. #SECOND STAGE.
      17. #here the script checks if swap is already commented, if it isn't it adds the # and rewrites the actual fstab.
      18. #in case there is no swap entry the script will run anyway and will just rewrite the fstab.
      19. #I could have easily avoided the # check, but the result would have not looked very pro.
      20. #After all, the code is basically is the same as above so let's act like a pro for once.
      21. SWAP_COMMENT=`awk '$2~"swap" {a=$1;print a}' OFS="\t" /tmp/tempfstab`
      22. if echo "$SWAP_COMMENT" | grep -q "#";
      23. then
      24. #matched, we copy the work file over fstab (overwriting it) and call it a day
      25. cp /tmp/tempfstab /etc/fstab
      26. else
      27. #no match, erasing and rewriting fstab
      28. rm /etc/fstab
      29. awk '$2~"swap" {$1="#"$1}1' OFS="\t" /tmp/tempfstab >> /etc/fstab;
      30. fi
      31. #SANITY CHECKS, we are playing with fstab, any screwup will mean that the system will NOT boot,
      32. #so let's see if everything is ok before quitting the script.
      33. FLAG=0
      34. CHECK_A=`awk '$2~"^/$" {a=$1;print a}' OFS="\t" /etc/fstab`
      35. CHECK_B=`awk '$2~"^/$" {a=$1;print a}' OFS="\t" /tmp/testfstab_backup`
      36. if echo "$CHECK_A" | grep -q "$CHECK_B";
      37. then
      38. #matched, root entry is still there.
      39. echo;
      40. else
      41. #ops, there is an issue, raising flag.
      42. FLAG=1
      43. fi
      44. CHECK_A=`awk '$2~"^/$" {a=$3;print a}' OFS="\t" /etc/fstab`
      45. CHECK_B=`awk '$2~"^/$" {a=$3;print a}' OFS="\t" /tmp/testfstab_backup`
      46. if echo "$CHECK_A" | grep -q "$CHECK_B";
      47. then
      48. #matched, root fs type is there.
      49. echo;
      50. else
      51. #ops, there is an issue, raising flag.
      52. FLAG=1
      53. fi
      54. CHECK_A=`awk '$2~"^/$" {a=$4;print a}' OFS="\t" /etc/fstab`
      55. CHECK_B=`awk '$2~"^/$" {$4="noatime,"$4;print a}' OFS="\t" /tmp/testfstab_backup`
      56. if echo "$CHECK_A" | grep -q "$CHECK_B";
      57. then
      58. #matched, the options are all there and the modification is also there.
      59. echo;
      60. else
      61. #ops, there is an issue, raising flag.
      62. FLAG=1
      63. fi
      64. #again I could have left the swap out, but why not acting like a pro again?
      65. CHECK_A=`awk '$2~"swap" {a=$1;print a}' OFS="\t" /etc/fstab`
      66. CHECK_B=`awk '$2~"swap" {a="#"$1;print a}' OFS="\t" /tmp/testfstab_backup`
      67. if echo "$CHECK_A" | grep -q "$CHECK_B";
      68. then
      69. #matched, swap modification is there. (or there is no swap entry)
      70. echo;
      71. else
      72. #ops, there is an issue, raising flag.
      73. FLAG=1
      74. fi
      75. #good, now that we have run tests it is time to decide if we did the right thing.
      76. if [ $FLAG -eq 1 ] ;
      77. then
      78. #ah damn, something went wrong, reloading backup fstab
      79. cp /tmp/testfstab_backup /etc/fstab ;
      80. else
      81. #nice, it seems everything went right, good job everyone.
      82. echo;
      83. fi
      84. #HOUSEKEEPING TIME. the script will erase the workfile in /tmp and the backup fstab
      85. rm /tmp/tempfstab
      86. rm /tmp/testfstab_backup
      Display All


      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.

      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.

      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.

      The post was edited 6 times, last by bobafetthotmail ().

    • 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!

      I host parts of the omv-extras.org Repository, the OpenMediaVault Live Demo and the pre-built PXE Images. If you want you can take part and help covering the costs by having a look at my profile page.
    • davidh2k wrote:

      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. :)

      The post was edited 8 times, last by bobafetthotmail ().

    • 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:

      Source Code

      1. total used free shared buffers cached
      2. Mem: 3930108 3773872 156236 0 165084 2370016
      3. -/+ buffers/cache: 1238772 2691336
      4. 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.
    • @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 4.1.13 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • gyroland wrote:

      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. 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.

      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

      Source Code

      1. 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.

      The post was edited 7 times, last by bobafetthotmail ().

    • ryecoaaron wrote:

      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).

      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.

      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.

      Shell-Script

      1. #!/bin/bash
      2. #this is a proof of concept, any safety check is disabled.
      3. #FIRST STAGE
      4. #awk reads the fstab and adds noatime, then the output is dumped in /tmp/tempfstab work file
      5. #awk adds noatime mount option to all lines that match the conditions:
      6. #-start with /
      7. #-don't begin with "/proc" "/media" (the data drives are mounted inside /media in OMV)
      8. #-does not begin with a # (i.e. is not a comment)
      9. #-it is not a tmpfs nor a ramfs (we don't care of writes in tmpfs and ramfs because they are filesystems in RAM)
      10. #-its mount options don't contain "bind" (bound folders in the fstab, advanced stuff, does not need noatime)
      11. #-it does not contain another noatime already
      12. awk ' {
      13. if ($2~"^/" && $2!~/^\/proc/ && $2!~/^\/media/ && $1!~/#/ && $3!~/tmpfs/ && $3!~/ramfs/ && $4!~/noatime/)
      14. print $1, $2, $3, "noatime,"$4;
      15. else
      16. print}' OFS="\t" /etc/fstab >> /tmp/tempfstab
      17. #the next two lines are here for debugging, in the actual script they will be left commented
      18. echo ============FIRST STAGE OUTPUT==============
      19. cat /tmp/tempfstab
      20. #SECOND STAGE
      21. #here the script checks if swap is already commented, if it isn't awk adds the # and then rewrites the actual fstab.
      22. #in case there is no swap entry the script will run anyway and will just rewrite the fstab.
      23. #I could have easily avoided the # check, but the result would have not looked very pro.
      24. #After all, the code is basically is the same as above so let's act like a pro for once.
      25. #btw, I could have easily integrated this second stage into the first, but keeping it separated allows to control
      26. #it, so that it can be linked to a nice checkbox saying
      27. #"you want to deactivate swap? (recommended if you have installed OMV in a USB flash drive or in a SD card)"
      28. #but that requires the script to read a variable about swap when it is first called,
      29. #and that is not implemented at the moment.
      30. awk ' {
      31. if ($1!~/#/ && $3~/swap/)
      32. print "#" $1, $2, $3, $4;
      33. else
      34. print}' OFS="\t" /tmp/tempfstab >> /etc/fstab
      35. #the next two lines are here for debugging, in the actual script they will be left commented
      36. echo ========SECOND STAGE OUTPUT===============
      37. cat /etc/fstab
      38. #Sanity checks not implemented because this is just a proof of concept awaiting approval.
      39. #If you like it they can be implemented later.
      40. #Would be cool if you could implement them yourself, but can do it myself if you give the green light.
      41. #housekeeping time. the script will erase the workfile in /tmp
      42. rm /tmp/tempfstab
      Display All


      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.

      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.

      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 royvanrijn.com/blog/2013/12/6-traits-of-good-programmers/
    • bobafetthotmail wrote:


      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.

      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.

      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.

      It's complex even for me, so it's probably well above your own scripting skills, and most users can live without anyway.

      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 royvanrijn.com/blog/2013/12/6-traits-of-good-programmers/

      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 4.1.13 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:

      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.

      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.

      Meniak wrote:

      I don't think a complete noob user should use OMV.
      I guess you never read what it says on the tin.
      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
      .


      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.

      The post was edited 5 times, last by bobafetthotmail ().

    • 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 4.1.13 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      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.
      bugzilla.redhat.com/show_bug.cgi?id=1113777
      bugs.launchpad.net/linux/+bug/499237

      tekkb wrote:

      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.

      The post was edited 2 times, last by bobafetthotmail ().

    • 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 4.1.13 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.13
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      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

      Source Code

      1. 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.

      bugzilla.redhat.com/show_bug.cgi?id=1113777
      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.

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