GFS2 is a journaled file system, and as such should be able to repair damage to the file system on its own. However, faulty hardware has the ability to write incomplete blocks to a file system thereby causing corruption that GFS2 cannot fix. The first step to ensuring a healthy file system is the selection of reliable hardware (i.e. storage systems that will write complete blocks - even in the event of power failure).
Note: Most file system checkers will not check the file system if it is "clean" (i.e. unmounted since the last use). The fsck.gfs program behaves differently because the storage may be shared among several nodes in a cluster, and therefore problems may have been introduced on a different computer. Therefore, fsck.gfs2 will always check the file system unless the -p (preen) option is used, in which case it follows special rules (see below).
This prints out the proper command line usage syntax.
By specifying this option, fsck.gfs2 will only show the changes that would be made, but not make any changes to the filesystem.
Note: If the file system has locking protocol lock_nolock, the file system is considered a non-shared storage device and the fsck is deemed safe. However, fsck.gfs2 does not know whether it was called automatically from the init process, due to options in the /etc/fstab file. Therefore, if the locking protocol is lock_dlm and -a or -p was specified, fsck.gfs2 cannot determine whether the disk is mounted by other nodes in the cluster. Therefore, the fsck is deemed to be unsafe and a warning is given if any damage or dirty journals are found. In that case, the file system should be unmounted from all nodes in the cluster and fsck.gfs2 should be run manually without the -a or -p options.
Print out the program version information.
Print more information while running.
By specifying this option, fsck.gfs2 will not prompt before making changes.