UNIX System Administration Handbook - Evi Nemeth [89]
The umount command for unmounting filesystems accepts a similar syntax. On most systems, you cannot unmount a filesystem that a process is using as its current directory or one on which files are open. There are ways of getting around this constraint; see page 62.
Enabling swapping
One of the early advantages of UNIX was its implementation of virtual memory. This feature allows the operating system to pretend that the machine has more memory than it actually does. If processes try to use this “extra” memory, the system’s disks are brought into use as a kind of ultra-slow RAM. Juggling the contents of memory to and from disk is known as swapping or paging.9
To make swapping efficient, raw partitions (partitions without filesystems) are normally used as the backing store. Instead of using a filesystem structure to keep track of the swap area’s contents, the kernel maintains its own simplified mapping from memory blocks to disk blocks. It’s also possible to swap to a file in a filesystem partition, but this configuration is slower than using a dedicated partition.
The more swap space you have, the more virtual memory your processes can allocate. The best swapping performance is achieved when the swap area is split among several drives (or better yet, among several SCSI buses).
See page 764 for more information about splitting swap areas.
You can manually enable swapping to a particular device, but you will generally want to have this function performed automatically at boot time. On most systems, swap areas can be listed in the fstab file, the same file that’s used to enumerate mountable filesystems. A swap entry looks something like:10
/dev/da0b none swap sw 0 0
During startup, a command (often swapon or swap) is run to enable swapping on all partitions listed in the fstab file. The vendor-specific sections starting on page 138 identify the particular command and syntax used by each system.
8.4 FSCK: CHECK AND REPAIR FILESYSTEMS
The UNIX filesystem is surprisingly reliable, and it does a remarkable job of coping with unexpected system crashes and flaky hardware. However, filesystems can become damaged or inconsistent in a number of ways.
Any time the kernel panics or the power fails, small inconsistencies may be introduced into the filesystems that were active immediately preceding the crash. Since the kernel buffers both data blocks and summary information, the most recent image of the filesystem is split between disk and memory. During a crash, the memory portion of the image is lost. The buffered blocks are effectively “overwritten” with the versions that were most recently saved to disk.
There are a couple of approaches to fixing this problem. Minor damage can usually be fixed with the fsck command (“filesystem consistency check,” spelled aloud or pronounced “fs check” or “fisk”). This isn’t a very architecturally elegant way of approaching the issue, but it works pretty well for all the common inconsistencies.
Journaling filesystems (aka logging filesystems) write metadata out to a sequential log file that is flushed to disk before each command returns. The metadata eventually migrates from the log to its permanent home within the filesystem. If the system crashes, the log can be rolled up to the most recent consistency point; a full filesystem cross-check is not required. This feature can save you many hours of boot time on a system with large filesystems.
Journaling is available on Solaris’s UFS filesystem and on VXFS for HP-UX. See the HP-UX example starting on page 143 for an explanation of how to enable journaling.
If some form of journaling is not available, you must wait for fsck to work its magic. The five most common types of damage are:
• Unreferenced inodes
• Inexplicably large link counts
• Unused data blocks not recorded in the block maps
• Data blocks listed as free that are also