Re: /run vs /var/run
On Monday 19 December 2005 11:49, Bernd Eckenfels <ecki@lina.inka.de> wrote:
> In article <[🔎] 20051218210932.GD25848@boogie.lpds.sztaki.hu> you wrote:
> > If /run is tmpfs, it means everything stored there eats virtual memory.
> > So a musch metter strategy would be to move everything from /run to
> > /var/run at the end of the boot process.
>
> tmpfs stores run ressources in vm more efficiently (since they are
> otherwise in th buffercache and the filesystem). And you cant really move
> the run ressources. I vote for having run a tmpfs and having /var/run ->
> symlinked to /run.
tmpfs also doesn't require any writes to a disk. Flash storage is getting
larger and cheaper and we should expect that the number of systems with no
moving parts will keep increasing. On such a system you want to put all the
small data that is written often on a RAM disk of some sort. The Familiar
distribution (based on Debian and used on iPaQ hand-held machines) used RAM
disks for /var/run and many other things.
I think it's generally a good idea to make the main Debian development tree
work well with flash storage whenever it doesn't hurt other areas of
performance.
Also as for sym-links, there's no reason why /var/run couldn't be used all
along. Imagine we have a system where /var is mounted from an LVM volume (or
something else that can't be mounted early on). So we start with a /var
mount-point which has a /var/run mount-point under it and we mount our tmpfs
there. We then use the --bind option of mount to have it also mounted
as /etc/run (or whatever). Then we have daemons started etc which do things
under /var/run without any modification to their previous operation. When
the real /var file system is mounted mount --bind or --move is used to put
the file-system back on /var/run from /etc/run. Optionally we could have
special-case code in the script that does mount -a to have it umount /var/run
first.
I believe that this idea is significantly better than the /run suggestion. It
requires changing no other programs, gives the potential of performance
benefits (RAM being faster than disk) and system reliability benefits on
flash storage systems, and doesn't require breaking the FHS.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Reply to: