SWAP partition needed when running OMV in USB Stick?

  • Hello guys,


    I am sorry if the answer to this question is in the forum but I did look and didn't find it...
    When running OMV on a usb stick or microsd flash, the pluggin "Flash memory" is needed in order to avoid the massive read/writes on the flash memory and therefore to break it.
    When installing the pluggin, one need to "comment out the swap partition" in etc/fstab as part of the instructions.


    Well...my question is then... Do we need a swap partition in this case or can we just remove it with gparted and take benefict from this space for the system partition in EXT4? I would say we can remove it but maybe I am missing something so I need confirmation.



    Thank you in advance.

  • The requirement for swap depends on how much memory your system has. I have 16GB of RAM in my OMV server and have run it with 8GB in the past and run it without swap. I have never had a problem. And if your hardware isn't really ancient, you can't even find RAM modules that would be too small to run without swap enabled.


    I suggest that you disable swap in fstab, and reboot, but leave the swap partition in place on the disk for a while. If your machine runs out of RAM under heavy use, it will then crash because there is no available swap. If this happens reboot it, immediately re-enable swap in fstab, and reboot it again. If you are forced to re-enable swap I would like to know how much RAM you have :)


    If the machine doesn't run out of RAM and crash, then you can delete the swap partition and make use of that space.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    Einmal editiert, zuletzt von gderf ()

  • The requirement for swap depends on how much memory your system has. I have 16GB of RAM in my OMV server and have run it with 8GB in the past and run it without swap. I have never had a problem. And if your hardware isn't really ancient, you can't even find RAM modules that would be too small to run without swap enabled.


    I suggest that you disable swap in fstab, and reboot, but leave the swap partition in place on the disk for a while. If your machine runs out of RAM under heavy use, it will then crash because there is no available swap. If this happens reboot it, immediately re-enable swap in fstab, and reboot it again.


    If the machine doesn't run out of RAM and crash, then you can delete the swap partition and make use of that space.


    Hi,


    it is already as this as required by the "flash memory" pluggin that requires to comment the swap partition to avoid any over-writes in the flash memory. That's the reason I am asking if it's already commented, then I guess I don't need the partition in the drive and I can benefict from additiional space.




    siulman@omv:/srv/Data$ cat /etc/fstab
    # /etc/fstab: static file system information.
    #
    # Use 'blkid' to print the universally unique identifier for a
    # device; this may be used with UUID= as a more robust way to name devices
    # that works even if disks are added and removed. See fstab(5).
    #
    # <file system> <mount point> <type> <options> <dump> <pass>
    # / was on /dev/sdf1 during installation
    UUID=bf71f21c-e6d3-4650-ae60-7765056a76fa / ext4 noatime,nodiratime, errors=remount-ro 0 1
    # swap was on /dev/sdf5 during installation
    #UUID=92096a5f-ee5f-4efe-aaaf-c610f8cc9685 none swap sw 0 0
    tmpfs /tmp tmpfs defaults 0 0
    # >>> [openmediavault]
    /dev/disk/by-label/Data /srv/dev-disk-by-label-Data ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
    /dev/disk/by-label/Media /srv/dev-disk-by-label-Media ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
    /dev/disk/by-label/Backup /srv/dev-disk-by-label-Backup ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
    /dev/disk/by-label/VM /srv/dev-disk-by-label-VM ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,discard,acl 0 2
    # <<< [openmediavault]




  • I think you are missing the point.


    Unless your system memory is inadequate to run without swap, then the swap partition will not be written to at all. In this case, the Flash Memory plugin offers no benefit with respect to disk writes to swap - you can not reduce writes to swap that never happen in the first place - so just try running without swap first and see what happens.


    Why the Flash Memory plugin helps is because it moves the the more heavily written to areas of the physical disk into RAM disks (primarily the logs and RRD graph data).


    If you don't have enough RAM, then you must have swap on disk. And if you don't have enough RAM you can't further reduce available RAM by utilizing some of it for the RAM disks that the Flash Memory plugin sets up and uses.


    Another way to look at this is to say that using the Flash Memory plugin on a system that will not run without active swap space is pointless. You will either have an unstable system that crashes due lack of swap, or if swap is enabled on a delicate Flash type drive, and it has to be enabled to keep the machine running, you might burn out the disk eventually.


    It's all about having enough RAM, period. That's why I suggested disabling swap and running with the Flash Memory plugin for a while. If you can't keep the machine running, then get more RAM and then try again.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • Understood.


    Thanks for the explanation.


    I just tryed to move my OMV system from the USB stick to a 2.5 HDD in USB. Then I removed "Flash memory" pluggin as long as noatime,nodiratime in /etc/fstab and re-enabled "swap" partition in /etc/fstab too.
    Something weird is happening... It is taking a lot of time to boot because of this....


    Would you know what is it?


    "A start job is running...."


    At the end, it boots and everything is ok but it delays A LOT the booting process... a couple of minutes. I tryed to reboot a couple of times but nothing changed.


    Please help.





    UPDATE:


    Got it, that was was easy.... When migrating from USB stick to 2.5 HDD I had to use gparted to use the unallocated size (new HDD was bigger than the stick) and I needed to change the swap partition (remove and re-create) so at the end the UUID changed. Updating the UUID in /etc/fstab fixed it.


    Do you know how to check that the "flash memory" was completely reverted and my system is running in a "standard mode" and it does not (quoting you): "move the the more heavily written to areas of the physical disk into RAM disks (primarily the logs and RRD graph data)"

    ??

  • A UUID change will cause that loooooooooong pause you were seeing. Wasn't that annoying?


    One way to see if the Flash Memory plugin is in use is to open a shell and type:


    df -h


    If you see stuff like the below (folder2ram) those are the RAM disks the Flash Memory plugin sets up and uses.


    folder2ram 7.9G 32M 7.8G 1% /var/log
    folder2ram 7.9G 20K 7.9G 1% /var/tmp
    folder2ram 7.9G 1.2M 7.9G 1% /var/lib/openmediavault/rrd
    folder2ram 7.9G 1.9M 7.9G 1% /var/spool
    folder2ram 7.9G 36M 7.8G 1% /var/lib/rrdcached
    folder2ram 7.9G 8.0K 7.9G 1% /var/lib/monit
    folder2ram 7.9G 0 7.9G 0% /var/lib/netatalk/CNID
    folder2ram 7.9G 496K 7.9G 1% /var/cache/samba

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.



  • I think I am ok then.


    Thanks man! that was instructive. Sending a like!



    siulman@omv:/$ df -h
    Filesystem Size Used Avail Use% Mounted on
    udev 10M 0 10M 0% /dev
    tmpfs 1.2G 8.9M 1.2G 1% /run
    /dev/sdd1 135G 2.5G 126G 2% /
    tmpfs 2.9G 4.0K 2.9G 1% /dev/shm
    tmpfs 5.0M 0 5.0M 0% /run/lock
    tmpfs 2.9G 0 2.9G 0% /sys/fs/cgroup
    tmpfs 2.9G 1.7M 2.9G 1% /tmp
    /dev/sda1 59G 39G 21G 66% /srv/dev-disk-by-label-VM
    /dev/sde1 1.8T 524G 1.3T 29% /srv/dev-disk-by-label-Backup
    /dev/sdb1 2.7T 375G 2.4T 14% /srv/dev-disk-by-label-Data
    /dev/sdc1 2.7T 780G 2.0T 29% /srv/dev-disk-by-label-Media
    siulman@omv:/$



    Last question if I may. Do you know how to backup only the effective DATA used in a disk when doing a clonezilla? Because if you try to restore in a smaller disk it just does not work....

  • I have never tried this, but it is supposed to allow clonezilla to restore an image to a smaller disk.


    Select Advanced mode and use the -icds option.


    Just be sure that the actual amount of data being restored really will fit onto the smaller drive.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    • Offizieller Beitrag

    have never tried this, but it is supposed to allow clonezilla to restore an image to a smaller disk.


    Select Advanced mode and use the -icds option.


    Just be sure that the actual amount of data being restored really will fit onto the smaller drive.

    It does work some times but not always. I have used it many times. It usually fails the most when going to a much smaller drive.

    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

    Dude... you have your usb stick plugged in!! That is where the other kernel is coming from in your other thread.


    Run a long test on the 2.5" drive. Really up to you if you want to risk using the drive. If you have a backup and handle a bit of downtime, don't worry about the 2.5" drive.

    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!

  • The /dev/sdd is the HDD 2.5 plugged via USB. It’s the one that olds OMV right now where the system runs and the one that just showed the red light.
    The long test is running right now. I am not able to measure the risk according to the information provided by SMART. I understand the some sectors are failing but I don’t konw how risky it is or the probability of everything failing....
    do you?

    • Offizieller Beitrag

    Relocating sectors can be done for many reasons. I cant measure risk for you but I wouldnt use it for an important system. I might use it for a test system.

    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!

  • I've heard about that failure too, but it's worth a try.


    I think Parted Magic can handle this well, but is not a freebie.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • Relocating sectors can be done for many reasons. I cant measure risk for you but I wouldnt use it for an important system. I might use it for a test system.


    Understood...


    Would it be less risky to go back to one of the USBs sticks that I have at home? ^^
    The SMART does not work on flash drives so I would never now the potential failure...

    • Offizieller Beitrag

    If they are new usb sticks and you use the flashmemory plugin, they might be better.


    I’ve seen flash fail before smart would report
    it. So I dont waste my time with smart.

    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!

  • If they are new usb sticks and you use the flashmemory plugin, they might be better.


    I’ve seen flash fail before smart would report
    it. So I dont waste my time with smart.

    Ok then, I am rolling back to usb stick with “flash memory” plugin as I have some of them at home and it would be easier and quicker to replace one 4G or 8G usb stick by another one 4G or 8G with clonezilla than replacing an HDD 2.5 150Gigs by an USB stick 4G/8G.


    I could even keep one “backup stick” plugged in, in case the primary fails just restore clonezilla to the other one with my ILO.

Jetzt mitmachen!

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