UNIX System Administration Handbook - Evi Nemeth [87]
• A block usage summary
• A set of data blocks
Each filesystem partition is divided into cylinder groups of from 1 to 32 cylinders each. Structures such as inode tables are allocated among the cylinder groups so that blocks that are accessed together can be stored close to each other on the disk. This grouping reduces the need to seek all over the disk when accessing blocks in the same file.
Inodes are fixed-length table entries that each hold information about one file. Since space for inodes must be set aside when UNIX does its initial structuring of the file-system, you must decide in advance how many of them to create. It is impossible to predict exactly how many files (inodes) will someday be needed; UNIX uses an empirical formula to guesstimate an appropriate number, based on the size of the partition and an average file size.
You can adjust the number of inodes either up or down when you create the filesystem: more inodes for filesystems with lots of small files (such as Usenet news partitions or source code repositories), and fewer inodes for filesystems with a few large files (such as a filesystem containing a database). The default value provides enough inodes to fill the disk with 2KB files, which is usually plenty.
A superblock is a record that describes the characteristics of the filesystem. It contains information about the length of a disk block, the size and location of the inode tables, the disk block map and usage information, the size of the cylinder groups, and a few other important parameters of the filesystem. Because damage to the superblock could erase some extremely crucial information, several copies of it are maintained in scattered locations. This was not always true: early filesystems were totally destroyed if the superblock became corrupted. If necessary, you can tell fsck to use an alternative superblock when rebuilding a damaged filesystem. newfs -N will show the locations of backup superblocks. Block 32 always holds a backup.
See page 136 for more information about fsck.
For each mounted filesystem, UNIX keeps both an in-memory copy of the superblock and several on-disk copies. The sync system call flushes the cached superblocks to their permanent homes on disk, making the filesystem consistent for a split second. This periodic save minimizes the amount of damage that would occur if the machine were to crash when the filesystem had not updated the superblocks. sync also flushes modified inodes and cached data blocks. Most systems perform a sync every 30 seconds to minimize the amount of data lost in the event of a crash.
A filesystem’s disk block map is a table of the free blocks it contains. When new files are written, this map is examined to devise an efficient layout scheme.
The block usage summary records basic information about the blocks that are already in use.
Setting up automatic mounting
A filesystem must be mounted before it becomes available to UNIX processes. The mount point for a filesystem can be any directory, but the files and subdirectories beneath it will not be accessible while a filesystem is mounted there. See page 62 for more information about mounting filesystems. Be sure that the partition you are mounting or checking has a valid filesystem on it—if you try to mount or fsck your swap partition, you can really mess things up.
After installing a new disk, you should mount new filesystems by hand to test that everything is working correctly. For example,
# mount /dev/sd1a /mnt
would mount the filesystem in the partition represented by the device file /dev/sd1a (device names will vary among systems) on the directory /mnt. If the filesystem is brand new, its contents should look something like this:
# ls /mnt
lost+found
The lost+found directory is automatically created when you build a filesystem. It is used by fsck in emergencies; do not delete it. The lost+found directory has some extra space preallocated so that fsck can store “unlinked” files there without having to allocate additional