Another command related to disk usage is quot, which summarizes filesystem ownership. The quot command reports the number of 1KB blocks used by each of the users in a specified filesystem.
Only the superuser can execute this command, because it accesses the disk special files. The command syntax is:
quot [options] block−special−file
where
block−special−file The filesystem block special file options
The usual filesystem related options An example:
quot devsd0h
devsd0h home: 68456 pam
29154 mindy 23693 george3
11466 bjl
..... .....
353 root 6 bin
5.6.4 Checking Filesystems: The fsck Command
A filesystem can be corrupted by any number of things: operator errors, hardware failures, etc. The fsck command it stands for filesystem check checks the filesystems consistency, reports any
encountered problems, and optionally tries to repair them sometimes such repairs can cause minor data loss. The fsck command interactively repairs inconsistent filesystem conditions.
fsck can encounter the following filesystem problems:
One block belonging to several files inodes •
Blocks marked as free but in use •
Blocks marked as used but free •
Incorrect link counts in inodes, indicating missing or excess directory entries •
Incorrect directory sizes •
Inconsistencies between inode size value and the amount of data blocks referenced in the address field
• Illegal blocks e.g., system tables within files
• Inconsistent data in the filesystems tables
•
Lost files nonempty inodes that fully identify files not listed in any directory — fsck places these orphaned files in the filesystem directory named lost+found each filesystem has its
own lost+found directory, so they can be recognized later by owners and reused; the name assigned to a lost file corresponds to the inode number
•
Illegal or unallocated numbers in directories •
On BSD, the fsck command is run automatically on boots and reboots. On System V, fsck is run at boot time on nonroot filesystems only if they have not been dismounted cleanly, i.e., if the system
crashed. A manual run of the fsck command is needed only occasionally: at boot, when fsck s
138
The syntax of the fsck command is:
fsck [options] spec_ file
where
spec_file The name of the filesystems special file options
Available options: −n |
−N Answer no to all prompts, and list problems but do not repair them
−y | −Y
Answer yes to all prompts Be careful when using this option It repairs all damage regardless of the severity
−p
Preens the filesystem and performs noninteractive repairs that do not change any files contents
−b nn Use an alternate superblock located at nn−th block −m
Perform a sanity check only — do not repair
−q
Quiet mode; removes nonreferenced named pipes and reconstructs the free list without comment
−f
Force filesystem checking regardless of the superblock status
−F type
Specify a filesystem type to be fsck −ed −V
Echo, but do not execute, the command; verify and validate a command line
The fsck command runs faster on character special files. However, the block device must be used for the root filesystem. If the filesystem is not specified, the fsck command checks all filesystems
listed in the filesystem configuration file etcfstab, or etcvfstab; this happens at boot time. Under AIX, the checking of filesystems is determined in the filesystem configuration file etcfilesystems if
the keyword check is true for a corresponding filesystem.
Normally, the fsck command runs with −p option, i.e., it silently fixes the following problems:
Link counts in inodes too large •
Missing blocks in the free list •
Blocks in the free list and also in files •
Incorrect counts in the filesystems table •
Nonreferenced zero−length files deleted •
Lost files placed in the filesystems lost+found directory, and named by their inode number •
More serious errors will be handled with a prompt for confirmation.
If fsck modifies any filesystem, it will display the message:
FILESYSTEM WAS MODIFIED
If the root filesystem is modified, an additional message also appears:
REBOOT UNIX
139
REMOUNTING ROOT FILESYSTEM
When modifications happen during a boot procedure, the reboot, or remount, is initiated automatically. If the fsck has been executed from the command line on the root filesystem, then the
reboot command has to be started manually, too:
reboot −n
The −n option is very important to prevent previous execution of the sync command, which flushes the output buffers and might, under these circumstances, recorrupt the filesystem the only case
when the system is rebooted without sync −ing the disks.
An example from the Apollo workstation and HP−UX:
fsck −y
fsck: devdskc201d6s0: root file system continue yn? y
devdskc201d6s0 Last Mounted on
Root file system Phase 1 — Check Blocks and Sizes
Phase 2 — Check Pathnames Phase 3 — Check Connectivity
Phase 4 — Check Reference Counts FREE INODE COUNT WRONG IN SUPERBLK
FIX? yes Phase 5 — Check Cyl groups
SUMMARY INFORMATION SUPER BLOCK SUMMARIES BAD BAD CYLINDER GROUPS
FIX? yes Phase 6 — Salvage Cylinder Groups
21806 files, 0 icont, 296674 used, 128312 free 1472 frags, 15855 blocks MARKING FILE SYSTEM CLEAN
FILE SYSTEM WAS MODIFIED REBOOT HP−UX; DO NOT SYNC USE reboot −n
It is not the end of the world to have messages about filesystem inconsistencies during system startup. As long as the fsck command can fix them, sometimes even in several attempts, everything
will be fine. However, it can be very upsetting if fsck fails; the failure usually indicates a more serious filesystem problem, frequently, a hardware−related problem that requires a more radical
approach. The fsck command can resolve many logical inconsistencies, but it cannot repair a broken disk.
fsck is a very time−consuming command; for a large filesystem, a complete check can take a while. This is why filesystems that were cleanly dismounted during system shutdown are skipped — they
will have no problems and checking them is a waste of the time. Also, the journaled filesystem the jfs type is the most robust with regards to corruption; if it is corrupted, the recovery is much faster.
The price paid for such robustness is additional overhead in the filesystem use; the online journaling of filesystem transactions requires more resources and time.
140
Chapter 6: UNIX Filesystem Layout
6.1 Introduction
In Chapter 5 we discussed the UNIX filesystem primarily from the user standpoint. UNIX users create, read, write, and purge files. And this is correct — UNIX filesystems exist to make the files
accessible to users. But there is a lot of work behind the scenes to fulfill this logical requirement. This part is done by the UNIX system itself, and it is mostly hidden from the users. But UNIX
administrators must be aware of this fact and should understand this process. Everybody knows that files reside on disk. They are saved somewhere, and when we need them, we get them. But
how it works is more mysterious.
We use the term filesystem layout to explain how the files are organized within the available disk space. UNIX files cannot exist out of the UNIX filesystems. UNIX filesystem is the vehicle to
organize storage resources in a usable way. The filesystem merges files in a hierarchical way and enables their physical storage, as well as access to the stored files when needed. This is always
true, independent of the filesystem type and organization.
The filesystem layout is the main topic discussed in this chapter. A thorough understanding of filesystem layout is extremely important for successful filesystem management. Once this important
topic is understood, many other UNIX issues will become automatically clear. Filesystem management is crucial for overall UNIX administration. This cannot be overstated. Just remember
what we said earlier: on UNIX everything is a file or file−like. Files are in the center of UNIX. Consequently managing the files is the core of UNIX administration.
Disk space can vary in size, type, characteristics, and even location a remote disk space can be used, just as the local one, and UNIX must respond to all possible situations. The total disk space
is usually partitioned into smaller storage entities convenient for more flexible use, and a separate UNIX filesystem is created in each storage entity. To make the created filesystem visible to users,
an additional step is required: it must be merged with other filesystems in an overall UNIX directory hierarchy, which we will address as an overall UNIX filesystem. Strictly speaking the overall UNIX
filesystem is not a filesystem per se, rather this is a set of merged filesystems ready for use.
UNIX filesystems are organized on two levels: physical and logical. Physical layout directly reflects the filesystem organization within a storage entity. It takes care of files parameters and maps them
into corresponding hardware parameters of the storage entity. However, the UNIX filesystem can be organized and managed in a more sophisticated way within a virtual logical storage space that is
built around physical entities. A new level of abstraction was introduced to make filesystem organization more flexible and powerful.
Logical layouts of a storage space and its physical counterpart do not have to be necessarily the same. A logical storage can be spread over a part of a disk, over a whole disk, or as in todays
modern UNIX flavors, over several disks. Nearly any combination of multiple partitions of multiple disks can be combined performance−wise in an extremely powerful way. Of course, a precise
mapping of the logical storage to the physical storage counterpart is crucial. Once this bidirectional relationship is firmly established, UNIX can manage files on a logical level only.
Logical storage entities are known as logical volumes, and the corresponding system software for their management is known as logical volume manager LVM. Logical volumes appeared at the
moment when the disk technology reached the point where disk size, speed, and price stopped to be issues. LVM is a relatively new UNIX topic; for most of the UNIX flavors it is still an optional piece
141
