Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
4.11. Repairing a File System
When nodes fail with the file system mounted, file system journaling allows fast recovery. However, if a storage device loses power or is physically disconnected, file system corruption may occur. (Journaling cannot be used to recover from storage subsystem failures.) When that type of corruption occurs, you can recover the GFS2 file system by using the
fsck.gfs2command must be run only on a file system that is unmounted from all nodes.
You should not check a GFS2 file system at boot time with the
fsck.gfs2command cannot determine at boot time whether the file system is mounted by another node in the cluster. You should run the
fsck.gfs2command manually only after the system boots.
To ensure that the
fsck.gfs2command does not run on a GFS2 file system at boot time, modify the
/etc/fstabfile so that the final two columns for a GFS2 file system mount point show "0 0" rather than "1 1" (or any other numbers), as in the following example:
/dev/VG12/lv_svr_home /svr_home gfs2 defaults,noatime,nodiratime,noquota 0 0
If you have previous experience using the gfs_fsck command on GFS file systems, note that the
fsck.gfs2command differs from some earlier releases of
gfs_fsckin the following ways:
- Pressing Ctrl+C while running the
fsck.gfs2interrupts processing and displays a prompt asking whether you would like to abort the command, skip the rest of the current pass, or continue processing.
- You can increase the level of verbosity by using the
-vflag. Adding a second
-vflag increases the level again.
- You can decrease the level of verbosity by using the
-qflag. Adding a second
-qflag decreases the level again.
-noption opens a file system as read-only and answers
noto any queries automatically. The option provides a way of trying the command to reveal errors without actually allowing the
fsck.gfs2command to take effect.
Refer to the
fsck.gfs2man page for additional information about other command options.
fsck.gfs2command requires system memory above and beyond the memory used for the operating system and kernel. Each block of memory in the GFS2 file system itself requires approximately five bits of additional memory, or 5/8 of a byte. So to estimate how many bytes of memory you will need to run the
fsck.gfs2command on your file system, determine how many blocks the file system contains and multiply that number by 5/8.
For example, to determine approximately how much memory is required to run the
fsck.gfs2command on a GFS2 file system that is 16TB with a block size of 4K, first determine how many blocks of memory the file system contains by dividing 16Tb by 4K:
17592186044416 / 4096 = 4294967296
Since this file system contains 4294967296 blocks, multiply that number by 5/8 to determine how many bytes of memory are required:
4294967296 * 5/8 = 2684354560
This file system requires approximately 2.6GB of free memory to run the
fsck.gfs2command. Note that if the block size was 1K, running the
fsck.gfs2command would require four times the memory, or approximately 11GB.
-yflag causes all questions to be answered with
yes. With the
-yflag specified, the
fsck.gfs2command does not prompt you for an answer before making changes.
- Specifies the block device where the GFS2 file system resides.
In this example, the GFS2 file system residing on block device
/dev/testvol/testlvis repaired. All queries to repair are automatically answered with
fsck.gfs2 -y /dev/testvg/testlvInitializing fsck Validating Resource Group index. Level 1 RG check. (level 1 passed) Clearing journals (this may take a while)... Journals cleared. Starting pass1 Pass1 complete Starting pass1b Pass1b complete Starting pass1c Pass1c complete Starting pass2 Pass2 complete Starting pass3 Pass3 complete Starting pass4 Pass4 complete Starting pass5 Pass5 complete Writing changes to disk fsck.gfs2 complete