Root file system size survey

[Philip Peake]

In article <253 at necis.UUCP> geo at necis.UUCP (George Aguiar ext. 224) writes:
>
>    I'm always running out of blocks on my root file system and it is a fixed
>size. This makes me wonder what other people do.
>
>How big is the typical root file system?  ________ Blocks
>
>What criteria do you consider when deciding how big to make the root
>file system?
>

Choosing the size for a root filesystem is always a compromise.
The manufactures of small "packaged" UNIX systems (almost) invariably
give too little space. However, if you have enough sources to re-configure
some of the system configuration, the following may be of some help.

There are normaly three types of activity on a root filesystem:

1)	"Normal", ie, file updates (modification of passwd file etc),
	and modification of various inode values (especially on tty
	special devices. This does not normaly involve "eating" any
	disc space.

2)	/tmp activity (this is where a fair proportion of your blocks
	dissapear). You really do need several Mb of tmp space for any
	system supporting more than one user and doing any real work.

3)	Pipes. Normaly inodes and data blocks will be allocated, but
	not written to (unless the system is heavily loaded). However,
	the blocks are allocated, and so are temporarily unavailable.

To help isolate these activities, and to improve "crash resistance", I
normaly suggest the following:

Use a seperate filestore for /tmp. If this is where your space dissapears
it will soon become obvious. This also has other advantages; a system
crach may leave the /tmp filestore mangled, but this is preferable to a
mangled root ! In reducing activity on root you improve its reliability.
At boot time it is probably faster to do an mkfs on the tmp filesystem
than to do an fsck, it also cleans it out for you !

Change the pipedev (device on which pipes are created) from the root
system to the /tmp file system. If you look at the damage after a crash,
a large proportion of the garbage on the root system comes from pipes,
so, putting these on the tmp system again improves root reliability.

If you make these two changes then the root system becomes virtualy
"read only" - not quite, because of inode changes, and things like
the passwd file. However, activity is very much reduced. The space
required is then simply the space required for all of the files normaly
present on your root, plus a bit spare for new utilities, passwd file
growth etc.

Things to watch for if you use this approach are:

1)	You can't use pipes until the pipedev is mounted.
	This isn't normaly a problem. If you are going to work
	in single user mode just remember to mount the filesystem.
	For multi user mode, make the mount the first thing in /etc/rc

2)	If you use a seperate filesystem for /tmp, don't make the
	mistake I have seen one manufacturer make, which is to create
	some temporary files *before* mounting on /tmp, and then
	wondering why the free space on root is slowly dissapearing ...


Philip Peake.

	------------------------------------------------------