Permanent /var directory, will I be safe?

For Developers
1

Hello

I again set up an extroot, and noticed that /var is a symlink to /tmp.

Are there any unexpected effects from having a permanent /var or possibly packages that expect /var to be temporary?

2

(Moved to the For Developers section.)

3

If you've got true SSDs or spinning-disk storage on SATA or USB 3.0, then I can't see any major problems. That's how the x86_64 platform generally works.

If you're using USB sticks or internal flash, then you may feel the pain of the relatively slow write speeds of that media. With USB sticks, 5 MB/s is pretty good for anything but the most expensive, large-capacity sticks. Flash media is definitely not recommended for "continual write" applications, as it has a relatively short lifespan, often measured in thousands of write/erase cycles for NOR memory. You could kill your flash in a few weeks or months.

Unless you've got a reason to preserve specific information over reboot, my opinion is to stick with RAM-backed tmp/var. The packages expect that to be the setup. If there are specific things that you want to preserve over boot, then you can always symlink the file/directory to, for example /persist/some_app_data_directory/

If you're so short on RAM that the typically small amount of storage in tmp/var is a problem, well, you've got bigger problems and should consider scaling down your application load or buying a different router.

1 Like
4

The problem here is that OpenWrt expects /var to be a symlink to a tmpfs backed /tmp/, changing this to a permanent location will break some deeply ingrained expectations around this assumption - and you will see both 'spectacular' and subtile breakage from changing this.

Food for thoughts (just scratching the tip of the ice berg):

  • /var/ usually is on tmpfs and tmpfs disappears while rebooting, so cleaning up stale files isn't necessary
    • /var/run/
    • /var/lock/
    • /var/tmp/
  • /var/ can't be on the overlayed rootfs, as applications have a reasonable expectation of inotify working on /var/ (overlayfs doesn't support inotify)
  • there are undoubtedly some applications accessing /tmp/var/ directly (or indirectly, by traversing the filesystem)
  • early boot issues (/var/run/ must be available (in writable condition) pretty early on in the boot process)
    • over-mounting issues (locks and states may be created early during the boot process, before the final fs is mounted on /var/, shadowing already existing files that are still in use)
  • …

None of these are unfixable (but fixing these will need more space for cleanup scripts) and they probably should be fixed, but the early adopters and proponents of these changes (as in you) will feel the pain of finding the problems and coming up with solutions. Especially as this will 'always' remain an expert's setting (on most devices you'd both run into problem with flash size and -wear), so less eyes to find and fix issues..

4 Likes