remove / turn off folder2ram

I don't have a ton of memory (4G), and I keep running into out of memory 'freezes'. I'm wondering if turning off folder2ram will help. I have a conventional disk, so I don't really need it. Just turned it on as a newbie might twist all the dials to see what they do

One, how can I best identify the impact on ram usage?

Two, what is the correct order of operations to disable folder2ram if I did the fstab modifications in the GUI notes? (Add noatime and nodiratime to root options, comment out the swap partition)

My first guess would be to reverse the edits, then reboot, then disable the plugin.

macom,

thanks.

folder2ram 2.0G 32M 1.9G 2% /var/log

folder2ram 2.0G 0 2.0G 0% /var/tmp

folder2ram 2.0G 2.8M 2.0G 1% /var/lib/openmediavault/rrd

folder2ram 2.0G 20K 2.0G 1% /var/spool

folder2ram 2.0G 25M 1.9G 2% /var/lib/rrdcached

folder2ram 2.0G 4.0K 2.0G 1% /var/lib/monit

folder2ram 2.0G 1.6M 2.0G 1% /var/cache/samba

I've got 4G, so I imagine it tries to allocate 50%. I'm gonna shut it off and see how it impacts performance & oom errors.

ryecoaaron, thanks, up and running.

ryecoaaron, I don't think I got the swap back.

May 16 19:10:35 openmediavault systemd[1]: dev-disk-by\x2duuid-33ab2122\x2d943c\x2d4b08\x2d80a1\x2dcbe6051adef4.device: Job dev-disk-by\x2duuid-33ab2122\x2d943c\x2d4b08\x2d80a1\x2dcbe6051adef4.device/start timed out.

May 16 19:10:35 openmediavault systemd[1]: dev-disk-by\x2duuid-33ab2122\x2d943c\x2d4b08\x2d80a1\x2dcbe6051adef4.swap: Job dev-disk-by\x2duuid-33ab2122\x2d943c\x2d4b08\x2d80a1\x2dcbe6051adef4.swap/start failed with result 'dependency'.

May 16 19:10:35 openmediavault systemd[1]: dev-disk-by\x2duuid-33ab2122\x2d943c\x2d4b08\x2d80a1\x2dcbe6051adef4.device: Job dev-disk-by\x2duuid-33ab2122\x2d943c\x2d4b08\x2d80a1\x2dcbe6051adef4.device/start failed with result 'timeout'.

I'm getting this now every 30 min in my logs. I read this long string is the UUID of the original swap space.

fstab:

# 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/sda1 during installation
UUID=3f541e90-00e0-447b-afc1-ce422a3df23d /               ext4 noatime,nodiratime,errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=33ab2122-943c-4b08-80a1-cbe6051adef4 none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
# >>> [openmediavault]
/dev/disk/by-label/500g         /srv/dev-disk-by-label-500g     ext4    defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
/dev/disk/by-label/700g         /srv/dev-disk-by-label-700g     ext4    defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl  0 2
/dev/disk/by-label/1T           /srv/dev-disk-by-label-1T       ext4    defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl  0 2
/dev/disk/by-label/3Ta          /srv/dev-disk-by-label-3Ta      ext4    defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl  0 2
/dev/disk/by-label/3Tb          /srv/dev-disk-by-label-3Tb      ext4    defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl  0 2
/srv/dev-disk-by-label-500g:/srv/dev-disk-by-label-700g:/srv/dev-disk-by-label-1T:/srv/dev-disk-by-label-3Ta            /srv/2b1b4b4a-057f-485e-9085-2b7d5b0c26f3       fuse.mergerfs   defaults,allow_other,c$
# <<< [openmediavault]

result of blkid:

root@openmediavault:~# blkid
/dev/sda1: LABEL="system" UUID="3f541e90-00e0-447b-afc1-ce422a3df23d" TYPE="ext4" PARTUUID="8f80a8c1-01"
/dev/sdb1: LABEL="500g" UUID="71860502-8460-4b63-92d1-5a7a39c1dde6" TYPE="ext4" PARTUUID="5f9fe823-d5ca-4baf-b5d6-2a8bc483a534"
/dev/sdd1: LABEL="1T" UUID="28a3020b-db12-4565-805b-b9336b404670" TYPE="ext4" PARTUUID="ade28930-3784-4744-a900-cda819ef6d0d"
/dev/sdf1: LABEL="3Tb" UUID="c9dc50a0-5768-4a3e-af18-87cf87b91aa8" TYPE="ext4" PARTUUID="79b20241-3963-45d5-adfc-51338193238f"
/dev/sde1: LABEL="3Ta" UUID="bd940368-d704-4831-a0e6-f350b0d13e49" TYPE="ext4" PARTUUID="79f183d1-d8a9-4533-ace6-23a7db705655"
/dev/sdc1: LABEL="700g" UUID="48506cf6-ef3f-4c08-abcf-83a33d3a29b5" TYPE="ext4" PARTUUID="e0490ce7-6245-45ba-8634-b05c814c77a8"
/dev/sda5: PARTUUID="8f80a8c1-05"

So, maybe the sda5 was the old swap space?

A guy in this thread has a procedure which looks like a likely template, but I'm nervous about gparted...

I got a new UUID assigned to the former swap partition and edited fstab to use thew UUID. At reboot, it timed out waiting for that 'device' to activate, and moved on with normal booting. In processes, OMV says swap is 0 bytes. I used swapon /dev/sda5 at the command line, and now OMV shows swap active. Time for a reboot.

It doesn't hold through reboot. I get "a start job is running for /dev/disk/by-uuid... " for the UUID of the swap area. After boot finishes, processes show swap doing nothing until after I run swapon. I triple checked the new UUID I put in fstab. Wondering what else I may have missed?

gderf, no resume file. Per the Flash Memory plugin 'optional' instructions:

7. If you disable swap, initramfs resume should fixed to avoid mdadm messages.

1. Remove the resume file:

rm /etc/initramfs-tools/conf.d/resume Update initramfs:update-initramfs -u

Which, I did seemed like a good idea at the time.

ryecoaaron, that's how I got the UUID back for sda5. before, it was just sitting there, no UUID, just a PartID. It has no LABEL, if that matters. So this time, I did swapoff, then mkswap -L swap -U "put-in-the-uuid-I-already-had" and it succeeded. Then, swapon gave me an error, couldn't find the swap device. So, I did swap on, using the -L swap option and -f, which is some sort of reinitialize. Seems to be working, but no idea yet if it holds through a reboot.

maybe I don't. But I was needlessly running folder2ram when I have the system on a standard hd. I'm running on 4. When Snapraid is cranking through a sync, I would often get into out of memory situations. Right now, with a bit of swap, it seems happy with a sync running.

Its funny, swap is active and functioning, but the syslog is still showing those swap/start failed with dependency errors every 30 minutes

ok, for the record...

I realized I can GIVE the swap any UUID, so I gave it the original UUID it had before I turned on folder2ram. I uncommented the original line in fstab. no error at reboot, no log entries every 30 min about swap. There had to be something else still looking for that original UUID at boot. And, damn, it's handy. Snapraid used the shit out of the swap yesterday for a full sync. Really glad I got it back.

bob is now my uncle