Curt Sampson writes:

> The reasoning behind my method here is a lot to do with being able
> to easily do a partial back up a system, and retain useful
> functionality.

This is a goal, but is not the only goal, and for many it is
not the most important goal.  For sites that back up /var for
other reasons it is not a goal at all.  In addition, your choice
of what is in your "Transient loss" category vs what is in your
"Permanent loss" category is not shared by all sysadmins or users.

I see at least two reasons for having a /var:

	1 - To reduce writes to the root and usr filesystems,
	    thus reducing the chance that they will get corrupted.
	    Perhaps allowing them to be mounted read-only.
	    (I currently mount /usr read-only and would love
	    to be able to mount root read-only.)

	2 - To allow /var to be backed up less often,
	    perhaps not at all.

Moving cron tabs out of /var will aid in the goal of not needing
to backup /var.  If they are moved into the root filesystem,
there are some disadvantages:

	/ needs to be bigger (for some sites a LOT bigger)

	A larger root takes longer to fsck, and root is normally
	not fsck-ed in parallel with other filesystems.  This
	hurts availability, and some sites care about this a lot.

	More writes to the root filesystem, increasing the chances
	that it will get corrupted.  A corrupted root filesystem
	*really* hurts availability.

	One more roadblock in the way of making root read-only.

Thor Lancelot Simon writes:

> We are *already* at a read-only state for root; the syslog socket move
> was the last of the changes to go into the NetBSD tree which I had had
> to maintain in my private tree for the embedded systems I sell

Are you saying a general purpose box can have a read-only root,
or are you counting on your embedded systems to not need to change
/dev entries, passwords, and such?

Havard.Eidnes@runit.sintef.no writes:

> However, folks having that many users on their
> systems should also take care to have a root file system with a
> little more headroom than what you'd get with a 15-20MB root.

A large system probably doesn't have /tmp in the root filesystem,
in which case you don't currently need much headroom in root.

Curt Sampson writes:

> And still nobody on the `don't move it' side has put forth a more
> general study of where things should go in the filesystem, as those
> on the `please move it' side have.

	Things that are not needed in single-user mode do not belong
	in the root filesystem.

	Things that generate disk writes should not be moved
	into the root filesystem.

One can look at this from various points of view, but it is
rarely a clean split:

	Cron tabs contain system configuration kinda stuff *and* user
	data kinda stuff.

	In some environments you want cron tabs to be read-only,
	in others you want them read-write.

	Some stuff in /var should be backed up, some
	doesn't need to be.

	Cron tabs contain config info, so they should be in /etc.
	Cron tabs vary, so they should be in /var.

I see two arguments for moving cron tabs from /var to /etc:

	To allow not backing up /var.

	Cron tabs contain config data, and thus belong in /etc.

If /var is too large to back up reasonably, it is easy enough
to have your backup script tar (or whatever) /var/cron/ off
to tape, or put a tarball on a filsystem that does get backed up.
This is site specific, plenty of sites do back up /var.

Crontabs also contain user data, and so don't belong in /etc.

Thus I feel that the arguments for moving cron tabs from /var to
/etc are fairly weak, and greatly outweighed by the arguments against,
such as writes to the root filesystem.

If you have partitions to spare, there other possible setups to consider,
such as:

	splitting /var into things needing backup and things not
	needing backup.  This will be site specific.

	have a /etc/multiuser partition, and have cron tabs be
	in /etc/multiuser/cron/tabs/

Given a limit of 8 partitions per disk, I'm not in a hurry
to use up a partition just for cron tabs.

Snoopy
snoopy percent sopwith dot uucp at qiclab dot scn dot rain dot com