Would this be a time to consider /var on tmpfs.

 

My idea would be to modify the unraid initramfs startup script. (rc.M???)

 

Possibly rename /var to /var.d before anything starts.

 

mkdir /var

mount a tmpfs on /var

mv or rsync --remove-sent-files from /var.d/ to /var

 

 

The benefit of having /var on tmpfs is you can control the memory.

If /var fills up, the kernel does not crash.

tmpfs "can" be swapped out for unused blocks.

 

or you could put a callout in rc.M.

I notice that you source /var/tmp/ident.cfg

Perhaps an INITEXEC= would be a script to execute before anything possibly starts.

I see all sorts of initialization and restores going on here in the rc.M

 

 

I'd like to only put /var/log onto a separate tmpfs because there are directories within /var that contain files critical to running, like /var/run and /var/local/...  I'm pretty sure it's only the log files that have potential of growing really large.

I'd like to only put /var/log onto a separate tmpfs because there are directories within /var that contain files critical to running, like /var/run and /var/local/...  I'm pretty sure it's only the log files that have potential of growing really large.

 

If someone ever decides to do any kind of mailer it will use /var/spool.

I had this issue and had to mount a tmpfs there so exim would work. (it worked quite well too).

If you are adding one line in the fstab for /var/log, it would only take a second or two more to add a second tmpfs line for /var/spool.  The tmpfs will not use any (memory) space unless files are written to them.

 

Joe L.