The problem with /var today

March 12, 2009

When /var was created, people took everything in /usr that got written to and just threw it all into one filesystem. After that, /var became the place that you put anything (besides config files and the like) that needed to change or be written to, regardless of why.

The problem is that /var has wound up with two very distinct sorts of data in it: private program data and public data. Private program data is the entire collection of caches, databases, and other tracking information that various programs use to do their jobs. Public data is everything that users and sysadmins create and look at, with things like /var/mail, /var/log, user crontabs, and so on. (On some systems this may include web pages, SQL databases, and more.)

This matters because the two have very different importances and need very different sorts of handling for things like backups and operating system upgrades. Fundamentally, you don't care about private program data as long as the program works right and you probably actively want to not preserve it when you do things like reinstall the system or roll back to a previous system snapshot. However, you absolutely must preserve public data when you do things like reinstall the system.

That the two sorts of data are aggressively commingled in /var causes all sorts of practical problems for system management. Effectively, /var has been turned into both a system filesystem and user filesystem, and the two generally require very different and conflicting treatment. Attempts to patch this up in software are awkward.

(For example, Sun's Live Upgrade stuff goes to all sorts of contortions to try to copy some bits of your public data between various copies and snapshots of your system's /var.)

The obvious solution is to split /var into two filesystems, one for each sort of data. Unfortunately, changing Unix filesystem habits is a lot of work (and work that really needs to be done by Unix vendors in order for it to stick).


Comments on this page:

From 198.236.64.23 at 2009-03-13 11:00:38:

My understanding was that the "public /var" was what /srv was supposed to be.

By cks at 2009-03-13 19:13:39:

I think that there's two problems with /srv

First, /srv is not quite complete, since (at least according to the FSSTND) it is specifically for things that are served from the system, not for all local data. If you run an IMAP server you might stretch it to cover /var/mail, but it will never cover things like /var/log or the directory of crontabs.

Second, in practice nothing seems to be using it. It only exists on Linux machines, and I've yet to find one that has anything in it (even on systems that run things like stock installed web servers). So in the future it might deal with some of this issue, but right now it's not doing anything.

From 83.145.208.36 at 2009-03-18 11:04:14:

While I do acknowledge that the described problem is real, I would like to express my opinion that much of the talk around UNIX filesystem layout seems to be artificial; it is like some people are determined to change the layout that has worked for decades merely in the name of change. (At the same time I do acknowledge that the change in this area has always been evolutionary and more or less arbitrary.)

I sincerely hope that the solution is not yet another directory in the root. This perceived necessity of change has already lead to /srv, /proc, /altroot, /stand, /emul, /opt, you name it. And don't forget /media because someone did not like the name of /mnt.

* * *

While at it, where did this brilliant idea came from that desktop environments are intelligent enough to know how people like to organize their files?

~/Desktop, ~/MyPictures, ~/Video... Notice the capital letters, in a true UNIX fashion.

Makes an old dog barf.

- j.

Written on 12 March 2009.
« The not so secret history of /var
Why I don't trust seteuid() and friends »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Thu Mar 12 23:22:34 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.