The problem with /var
today
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:
|
|