File System Maintenance with fsck and e2fsck, inodes, and Superblock

 < Day Day Up > 

This section looks at maintaining file systems. Most examples will refer to the Integrity server with SCSI that you worked on earlier in this chapter. Even so, the tools and utilities work the same way on the IA-32 system with IDE drives. Again, remember that to use almost all of these tools, you must be logged on as root.

fsck and e2fsck

fsck (file system check) is a program used for file system maintenance on Linux and UNIX systems. fsck checks file system consistency and can make many "life-saving" repairs to a corrupt file system. fsck can be run with several options. The program used for ext2 file systems checking is e2fsck. If you try running fsck on an ext2 or ext3 file system, you'll see that fsck automatically calls e2fsck. The following are some of the more commonly used options with e2fsck:

-b superblock

Normally, e2fsck uses block 1 to find partition related information. If, however, block 1 id is corrupted, you can specify a block number that usually exists every 8192 blocks. You'd specify 8193, 16385, and so on as alternates. You can also find backup superblocks by noting them when the files system is created (as shown in the earlier listing), or by using the mke2fs program using the -n option to print out where the super blocks were created. The -b option to mke2fs, which specifies blocksize of the filesystem must be specified in order for the superblock locations that are printed out to be accurate. See the man pages for e2fsck and mke2fs for more information.

-c

Runs the badblocks program to find bad blocks on the file system and adds them to the bad block inode.

-f

Forces checking of the file system even if it is thought to be clean.

-y

Responds yes to all questions so that e2fsck can be run non-interactively.

-v

Runs in verbose mode.


To run e2fsck on partition /dev/sdb1 with the -y and -v options, you would do the following:

 [root@localhost root]# umount /backup [root@localhost root]# e2fsck Usage: e2fsck [-panyrcdfvstFSV] [-b superblock] [-B blocksize]                 [-I inode_buffer_blocks] [-P process_inode_size]                 [-l|-L bad_blocks_file] [-C fd] [-j ext-journal] device Emergency help:  -p                   Automatic repair (no questions)  -n                   Make no changes to the filesystem  -y                   Assume "yes" to all questions  -c                   Check for bad blocks  -f                   Force checking even if filesystem is marked clean  -v                   Be verbose  -b superblock        Use alternative superblock  -B blocksize         Force blocksize when looking for superblock  -j external-journal  Set location of the external journal  -l bad_blocks_file   Add to badblocks list  -L bad_blocks_file   Set badblocks list [root@localhost root]# e2fsck /dev/sdb1 -y -v e2fsck 1.26 (3-Feb-2002) /dev/sdb1: clean, 11/4447744 files, 147791/8889961 blocks [root@localhost root]# 

Before you ran e2fsck, you first unmounted the /backup file system (umount /backup). Before you can check any filesystem, you must first be sure to unmount it. After you unmounted /backup, you then intentionally typed e2fsck without any options to see a summary of the command.

Since boot time, your system runs e2fsck on any file systems that were not marked as clean at the time you shut down the system, you can rest assured that when your system boots, any disks that were not properly shut down will be checked. Still, it is a good idea to unmount your file systems and run e2fsck interactively on a periodic basis just so you can see firsthand that all of your file systems are in good working order.

Should e2fsck find a problem with a directory or file, it would place these in the lost+found directory, which is at the top level of each file system. If a file or directory appears in lost+found, you may be able to identify the file or directory by examining it and moving it back to its original location. You can use the file, what, and strings commands on a file to obtain more information about it to help identify its origin.

How are file system problems created? The most common cause of a file system problem is improper shutdown of the system. The information written to file systems is first written to a buffer cache in memory. It is later written to the disk with the sync command by unmounting the disk, or through the normal use of filling the buffer and writing it to the disk. If you walk up to a system and shut off the power, you will likely end up with a file system problem. Data in the buffer that was not synchronized to the disk will be lost, the file system will not be marked as properly shut down, and e2fsck will run when the system boots. A sudden loss of power can also cause an improper system shutdown.

Proper shutdown of the system is described with the shutdown command. Although e2fsck is a useful utility that has been known to work miracles on occasion, you don't want to take any unnecessary risks with your file systems. So, be sure to properly shut down your system.

Inodes

You may see messages that include references to inodes when running e2fsck. Inodes are control mechanisms in Linux and UNIX that point to data blocks or other inodes on your storage subsystem. The inode contains the inode number, the length of the file, the file's creation date, the time the file was last accessed, the time the file was last changed, the time the inode was last changed, the owner of the file and group, the size of the file, the access rights, direct and indirect pointers to blocks of data, device numbers for special files, and a variety of other information. In the case of a directory, which is a simply a special type of file in Linux, the inode points to data blocks that contain important information about the files in the directory. Because the inode contains important information and pointer information, it is vital to the existence of a healthy file system.

In addition to inodes, you may also see information related to the superblock. The superblock contains important information about the disk on which it resides, such as the location of the first inode, the amount of available space, and so on.

     < Day Day Up > 


    Linux on HP Integrity Servers. A System Administrator's Guide
    Linux on HP Integrity Servers: A System Administrators Guide
    ISBN: 0131400002
    EAN: 2147483647
    Year: 2004
    Pages: 100

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net