"The Linux Gazette...making Linux just a little more fun!"

Filesystem Management: What must be "resident" at all times?

From peter on Sun, 02 May 1999

I'm familiar with moving a portion of a UNIX file system that doesn't need to be resident at all times to a larger partition. What's the safest way to do this for a portion of the file system (/usr ?) that needs to be resident at all times?

Thanks for your help,
Peter

The "resident" is not a "term of art" for Unix systems administration. Also /usr doesn't have to be mounted at all times. In particular you should be able to bring the system up in single user mode and peform most maintenance operations without /usr being mounted.

That's why we have a /sbin directory. Originally we had /bin, which was intended to contain just those files that were necessary to bring the rest of the system online. However, as UNIX systems developed shared libraries a number of the items which were traditionally located in /bin (such as sh --- the shell) came to depend on /usr/lib which was the traditional location of the .so (shared object) files.

So some vendors started creating a /sbin ('s' for "statically linked" --- which theoretically allows one to replace /bin with a symlink or use it as a mount point for its own filesystem. Of course most Linux distributions don't put statically linked binaries in /sbin --- we've moved many of the shared libraries into /lib.

Personally I think the whole arrangement is a bit ugly. The idea of having duplicate but statically linked versions of many commands in /sbin is feasible. Having /bin contain a set of symlinks to the /sbin command is fine (since they will work while nothing is mounted over /bin and the mount of any other filesystem over /bin will then make those symlinks "disappear"). I don't like this insistence on dynamically linked everything since that means that you can't even run ldconfig to fix the /etc/ld.so.cache file if it gets corrupted. You have to boot from a floppy to get anything done.

In any event: let's look at a typical Linux root directory

drwxr-xr-x   2 root     root         1024 Apr 16 12:52 bin
drwxr-xr-x   2 root     root         1024 Apr 16 05:20 boot
drwxr-xr-x   1 root     root         3072 Apr 25 11:11 cdrom
drwxr-xr-x   2 root     root        17408 Apr 25 07:00 dev
drwxr-xr-x  41 root     root         3072 Apr 25 11:11 etc
drwxrwsr-x   5 root     staff        1024 Apr 19 01:58 home
drwxrwsr-x   2 root     floppy       1024 Feb  1 04:42 floppy
drwxr-xr-x   2 root     root         1024 Feb  1 04:42 initrd
drwxr-xr-x   3 root     root         2048 Apr 16 12:38 lib
drwxr-xr-x   2 root     root        12288 Apr 16 04:46 lost+found
drwxr-xr-x   4 root     root         1024 Apr 19 03:41 mnt
dr-xr-xr-x   6 root     root            0 Apr 18 08:10 proc
drwx------   4 root     root         1024 Apr 22 15:42 root
drwxr-xr-x   2 root     root         2048 Apr 16 12:53 sbin
drwxrwxrwt   2 root     root         1024 Apr 25 12:41 tmp
drwxr-xr-x  15 root     root         1024 Apr 16 05:17 usr
drwxr-xr-x  17 root     root         1024 Apr 17 11:01 var

This is from a fairly new Debian 2.1 installation. Here's the same list with some commentary:

bin

contains many common commands. Should be able to put this on a mounted fs. Ironically the mount command is in this directory and is dynamically linked! That's just WRONG. (And I don't care what the FHS says about it).

boot

contains kernels and associates System.map files and backups of the boot sector, as created by /sbin/lilo. Oddly enough this can be a mounted filesystem. As I've described many times, Linux doesn't require that its kernel be located on its root filesystem. The System.map file isn't needed during the boot cycle (and isn't "needed" by much of anything --- 'lsof' seems to complain if I don't have one or if it's mismatched to my kernel version but that's about it).

dev

contains device nodes. MUST be on root fs. (Richard Gooch has written a special devfs --- sort of like /proc for device nodes. That would allow this to be a mounted filesystem)

etc

contains passwd, group files, startup scripts and the mtab (which tracks all of the mounted filesystems).

floppy

this is stupid. It's just a mount point. I prefer to put most of my mount points under /mnt --- so I have a /mnt/cdrom, a /mnt/floppy, /mnt/a (DOS floppy), and others.

home

This should be either a mount point or a symlink to some directory on a mounted fs. I sometimes use -> /usr/local/home if I have a small number of filesystems to work with.

initrd

I'd have put this under /boot. Anyway, mine is empty. This is intended to remount any "initial RAM disk" that was used. (I might do a kernel patch to move this) When a kernel has initrd support enabled (compiled in) then a compressed image of the initrd filesystem is appended to the kernel. The kernel then automatically creates the RAM disk, decompresses and copies the image into it, and runs the /linuxrc program that it should find there. (See /usr/src/linux/Documentation/initrd.txt for details). This doesn't have to be here if you don't want/need access to the initrd after boot.

lib

This MUST be on /; it contains your libc.so and other shared libraries on which almost ALL programs on your system depend.

lost+found

This must be at the top of every filesystem. fsck will link any "lost clusters" into nodes under this directory; giving you an opportunity to fix them. Indeed, you should probably have a script that periodically checks this and warns the sysadmin any time any of these directories are non-empty.

mnt

This is conventionally used as a mount point or as a directory containing a list of mount points. It's where you mount "temporary" and "removable" filesystems.

opt

This is a place to store large "optional" packages like WordPerfect, StarOffice, etc. I usually make this a symlink to /usr/local/opt

proc

This is a "virtual filesystem" a representation of the system's process state as a set of file nodes. The BSD systems that implement the proc filesystem typically do so much different than Linux. Under Linux you can read much more info from /proc entries, and more of it is represented a plain text. The idea of /proc is that we can have the kernel provide a filesystem/directory abstraction of its state and we can write programs like 'ps' and 'top' to use normal UNIX file semantics to read that information. Linux is unique in that you can also modify many proc entries to changed the system state. The most common case of this is to enable kernel routing using 'echo 1 > /proc/sys/net/ipv4/ip_forward'

root

this is the root user's home directory. Handy if you have any scripts or data/configuration files that you want to access during boot or single-user mode when /home will not be mounted.

sbin

as I've noted, this should contain statically linked versions of the files that you absolutely need to fix a broken system. Linux, like Solaris and other modern versions of UNIX has gone to the dark side of practically requiring shared libraries for EVERYTHING. While shared libraries are very useful for conversing disk space and memory and offer huge performance benefits --- they are just one extra thing to break (for robustness and security). So a decent compromise is to have a subset of statically linked programs for use when everything is broken. (Having a kernel module or patch that could automatically detect and repair a corrupt /etc/ld.so.cache file would be a pretty good idea, too).

tmp

this can be a mounted filesystem or a symlink to a directory on one.

usr

this normally should be a mounted filesystem

var

this can be mounted or a symlink.

Of course the preceding is all must my opinion. The most authoritative commentary on what Linux filesystems should look like is the FHS --- the Linux Filesystem Hierarchy Standard (co-ordinated by Dan Quinlan), homepage https://www.pathname.com/fhs/.

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 42 June 1999

HTML transformation by Heather Stern of Starshine Techinical Services, https://www.starshine.org/

	1	2	3	4	5	6
	7	8	9	10	11	12
	13	14	15	16	17	18
	19	20	21	22	23	24