Flash Memory Plugin on SSD

  • I am upgrading my OMV server to an SSD. As part of the upgrade, should I install the flash memory plugin as well, or is that intended more for SD cards and flash drives? The reason I ask is because some of the information that the flash memory plugin stores on the ramdisk is information that I would prefer to have saved in the event that the server's power gets cut.

    • Offizieller Beitrag

    I use it on my systems with flash drives and even virtual machines backed by flash drives. My systems also have battery backup but I guess I'm not that worried about losing the info. I guess you could set an hourly scheduled job to execute the folder2ram -syncall command. Then you would lose an hour at most.

    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!

  • should I install the flash memory plugin as well

    This is something you'll have to answer yourself :)


    The plugin will greatly reduce write amplification so it helps in any case with delaying wear out. But with usual SSDs this is not much of a concern with an OMV OS drive. So it's the best you simply monitor what's happening.


    If you've the SSD already, check output from 'smartctl -x' for the device. If there's an attribute called Total_LBAs_Written then write 100 MB in a bunch (dd if=/dev/urandom of=test bs=100M count=1 ; sync) and check again so you know how large the SSD thinks a LBA is. Then check output from /proc/diskstats, output from 'dumpe2fs | grep Lifetime', let the box run for a week and compare later the output again.

    • dumpe2fs will tell you what happenend at the filesystem layer
    • /proc/diskstats will tell you what happened at the block device layer
    • smartctl -x will tell you how much data really has been written at the flash layer (might be magnitudes higher due to high write amplification)

    Then install flashmemory plugin and check a week later again. Everything else is speculation. As soon as you remove the flashmemory plugin everything will be as before.


    BTW: SSDs that support Device Statistics (GP/SMART Log 0x04) will also show the real amount of data written.

    • Offizieller Beitrag

    Oops, I thought something like this would be running regularly? Or just with another frequency?

    It only runs at shutdown now. There was plenty of discussions about if it should be done and if so, how often. Personally, I don't need it to run since I don't care about anything I would lose. Others want to run it so often that it doesn't make sense to use the plugin. I don't know what the right answer is but since one can create a scheduled job, I leave it to the individual.

    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!

    • Offizieller Beitrag

    I would think SSD's or NVME drives are designed to handle an operating system, whereas thumb drives are not.

    True but they still have a finite number of writes. If you can reduce the writes, why not? :) Some might argue that some things are faster since they are read from and written to ram instead of disk especially on slower systems with slow ssds.

    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!

  • It only runs at shutdown now.

    Oh, that's good to know. I naively thought there would be an hourly sync. But you're right, it's easy to add this in the UI.


    I would think SSD's or NVME drives are designed to handle an operating system, whereas thumb drives are not.


    The latter is wrong (all my OMV hosts run off SD cards and this perfectly fine and I address the potential problem at the filesystem layer by using btrfs, snapshots and scrubs and if some day the OS 'drive' starts to die I'm up and running in no time by restoring the latest backup and starting over).


    And with all flash media it's all about write amplification. If you can reduce this it's a good idea especially with log files. 20 bytes of boring log contents written to an SSD that uses a 16 KiB page size will end up in a nice write amplification of 800 (your SSD is aging 800 times faster compared to collecting this boring log stuff in RAM and writing it back to the SSD only every few hours and then filling a whole page). As soon as stuff gets overwritten and the SSD has to run through an read-modify-write cycle and much larger Erase Blocks are affected it gets even much worse :)


    The concept is outlined here in section 3.3 for example: http://codecapsule.com/2014/02…-flash-translation-layer/

  • Well that took way too long. After spending hours playing around with Clonezilla and GParted, I was finally able to move my OMV image from my hard drive to my SSD. Now to install flash memory. As part of the move, I shrunk my swap partition to 5GB. Could this cause any issues?

  • Why do you want to use swap? It makes no sense at all. Do you have less than 256 MB memory?

    I don't want to use swap. The swap partition was already there from when I installed OpenMediaVault on my original HDD. I didn't want to remove it because I was concerned that doing so would cause problems, so I decreased its size from the original 16GB that it was down to 5GB. The server has 8GB of memory, so I wouldn't think that having a swap would be necessary given that I have never exceeded that according to the memory usage charts, but I kept it anyway because I thought removing it would be a problem. The original drive was 500GB, so a 16GB swap wasn't a big deal, but my new drive is only 64GB, and having a 16GB seemed like a waste of space that could be better used for creating a separate partition for storing data on the disk.

  • I decreased its size from the original 16GB that it was down to 5GB

    Swap on a SSD is somewhat useful but i would've changed the partition size to 0 and used zram instead.


    OMV on toys (ARM boards) doesn't use swap any more since there with SD cards as 'disk' it's game over once the first page gets swapped out --> everything would get that slow that people will reboot the NAS anyway. On the ARM images there's zram configured using 50% DRAM as default. No problem even on boards with just 256 MB DRAM (since the Linux kernel is not an idiot but pretty good in managing virtual memory)


    So I would remove the swap partition, remove the swap entry in fstab, set vm.swappiness to 0 and maybe install zram so in emergency situations when your system would be really running out of memory no problems will occur.

  • Hmm. I installed debian first and then omv3 on top of it due to not being able to get omv to install on NVME drive. As a result, I ended up with a 16gb swap partition. Can I easily fix that without mucking up my system?

  • Hmm. I installed debian first and then omv3 on top of it due to not being able to get omv to install on NVME drive. As a result, I ended up with a 16gb swap partition. Can I easily fix that without mucking up my system?

    Unless you want to use your NVMe SSD also for data there's nothing to fix anyway. The Linux kernel's virtual memory implementation is not made by idiots so chances are great that the same amount of data on a 16GB swap partition will be used as on a 512MB partition or on a 8TB partition: zero bytes. Since using swap makes no sense when amount of RAM is sufficient.


    What's the output from 'free' on your host?

  • No swap used and all the RAM just for caches. If you look with 'sysctl vm.swappiness' it's most probably the default (60). You can delete the swap partition, set vm.swappiness=0 (/etc/sysctl.conf) and sell 12 or even 14 GB DRAM and your NAS will perform the same. :)

  • Don't think I'll be selling any ram, but when the time comes to migrate to omv4 I will probably wipe the OS drive and start over so I'll redo the partitions then. Also thinking about switching to running OMV as a VM. Thoughts on that? Any hit to performance?

Jetzt mitmachen!

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