WeeboTech Posted July 20, 2010 Share Posted July 20, 2010 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 Link to comment
limetech Posted July 20, 2010 Share Posted July 20, 2010 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. Link to comment
WeeboTech Posted July 20, 2010 Author Share Posted July 20, 2010 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). Link to comment
Joe L. Posted July 21, 2010 Share Posted July 21, 2010 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. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.