[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: deprecating /usr as a standalone filesystem?

On Wed, May 06, 2009 at 12:30:14AM +0200, Stefano Zacchiroli wrote:

> Of course the problem is that if you update on the NFS server, then
> related /etc and /var files [1] will not get updated on the NFS client
> machines and you need to propagate changes there.

One thing to remember is when you export /usr (or "/") over NFS, then
you usually do not expect to install new software often (maybe once or
twice a year), and security updates rarely bring big changes under /etc
or /var.

/etc can be managed with a couple of scripts; if you have a non-trivial
amount of machines you already have the scripts to populate and
customize it for a new machine. After an update, you just re-run that
script for all the clients and you're done.

/var is not an issue either. You can mount it read-only just like /usr
and then you can mount some tmpfs instances over the locations where
write access is really needed. /etc/fstab fragment:

tmpfs	/tmp		tmpfs	size=100m,mode=1777	0	0
/tmp	/var/tmp	bind	bind			0	0
tmpfs	/var/log	tmpfs	size=10m		0	0
tmpfs	/var/lib/gdm	tmpfs	size=10m		0	0
tmpfs	/var/lib/xkb	tmpfs	size=10m		0	0
tmpfs	/var/lib/nfs	tmpfs	size=10m		0	0
tmpfs	/var/cache/hald	tmpfs	size=10m		0	0
tmpfs	/media		tmpfs	size=128k		0	0

You of course need a couple of mkdir/chown commands in an init script to
create some required subdirectories.

If you need persistence, then you mount a writable FS somewhere else,
and you do something like

	mount --bind /home/terem/boinc-client/$HOSTNAME /var/lib/boinc-client

(that's from a running cluster setup).

If I take a look of what is actually under /var on that cluster, then I

nfs-server# du -s .
147300	.
nfs-server# du -s cache lib/apt lib/aptitude lib/dpkg log
135616	total

So even if you want a local /var on every machine, you can ignore over
92% of the data when you synchronize with say rsync (you can actually
ignore even more, but then the above "du -s" line would have been too


     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences

Reply to: