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

# The Answer Guy

#### By James T. Dennis, linux-questions-only@ssc.com
LinuxCare, http://www.linuxcare.com/

### 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 http://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, http://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