Instead of just mounting tmpfs on /var/log I want to use overlayfs.

  1. /var/log are writable tmpfs, but containing files were there before tmpfs mount. This old files are not in memory of tmpfs but in lower layer.
  2. only changes are stored in tmpfs, while old and unmodified files stored on SSD
  3. sometimes it should be possible to write changes to SSD, for example via cron. This should free up tmpfs memory

So, result should be: logs written to RAM, old and new boot logs accesable via same path. Changes are written sometimes to disk, by script.

Point is to speed up a little, and safe SSD from many writes.

(I saw similar thing in puppy linux, not for logs, but for all changes to root, but without installing it can't do the same, documentation not helps)

I will do same for browser cookies/cache based on answer. But persistent write will be done on browser close. Can't turn off browser cache, need at least small cache to have same bugs in my web development as users can have because of cache.

  • "Point is to speed up a little, and save SSD from many writes." All you're really doing is reimplementing the disk cache layer. – roaima Jan 19 '19 at 12:49

Managed to make /var/log overlay, it shows SSD log files, and changes. All changes are kept in RAM. Later I'll do syncing, so changes become permanent every hour, by copying upper layer to lower.

#prepare layers
sudo mkdir -p /var/log.tmpfs
sudo mount -t tmpfs -o rw,nosuid,nodev,noexec,relatime,size=512m,mode=0775 tmpfs /var/log.tmpfs
sudo mkdir -p /var/log.tmpfs/upper
sudo mkdir -p /var/log.tmpfs/work
sudo chown -R root:syslog /var/log.tmpfs
sudo chmod -R u=rwX,g=rwX,o=rX /var/log.tmpfs

#prepare overlay
sudo mkdir -p /var/log.overlay
sudo chown root:syslog /var/log.overlay
sudo chmod u=rwX,g=rwX,o=rX /var/log.overlay

#start overlay
sudo mount -t overlay -o rw,lowerdir=/var/log,upperdir=/var/log.tmpfs/upper,workdir=/var/log.tmpfs/work overlay /var/log.overlay
sudo mount --bind /var/log.overlay /var/log

To make changes persistent, its needed to unmount bind /var/log, copy files, then bind again.

| improve this answer | |
  • 1
    why? what actual benefit do you gain from this? quickly fill up your RAM to trigger the kernel's OOM random-process-killer faster? – cas Feb 16 '18 at 4:54
  • 1
    Max size of tmpfs is set, so ram will not fill up. logrotate configs are tuned the way it never fill all reserved size. Anyway, I find out its not possible to make changes persistent online, so I have to deceide either remove this script or loose logs on reboot. This is normal for development server, not production. – LeonidMew Feb 16 '18 at 7:58
  • 1
    I still don't get what you were trying to achieve. Where's the benefit? there's certainly no performance benefit. It just seems like extra complication and fragility for no good reason. Probably qualifies as some form of premature optimisation: maybe something like "ram disks are fast so i'll put my logs on a tmpfs" without testing whether there's any actual, noticeable benefit. Hint: unless the logs are fsynced on every write, writes will be buffered anyway. – cas Feb 16 '18 at 8:02
  • SSD have large buffer it self, I just don't want that unnecessary writes. Ok, I get your point. Will not recommend it somebody, but stay with it for myself :) – LeonidMew Feb 16 '18 at 8:10
  • 1
    This is an excellent solution for a Raspberry Pi that loses power often and is subject to disk corruption if the SD card is writing while power is lost. Several key directories must be overlaid in addition to /var/log, but this solution lays the groundwork for creating a stable, read-only with ephemeral read/write support. – Brad Hein Dec 29 '19 at 19:36

I can suggest anything-sync-daemon. It pretty good job.


From the documentation,

anything-sync-daemon (asd) is a tiny pseudo-daemon designed to manage user specified directories referred to as sync targets from here on out, in tmpfs and to periodically sync them back to the physical disc (HDD/SSD). This is accomplished via a symlinking step and an innovative use of rsync to maintain synchronization between a tmpfs copy and media-bound backups. Additionally, asd features several crash recovery features.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.