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.
This option may not be used with the -y or -p/-a options.
If the file system has locking protocol lock_nolock, it is considered a non-shared storage device and it is considered safe. If the locking protocol is lock_dlm and -a or -p was specified, the check is considered unsafe as it cannot be determined whether the device is mounted by other nodes in the cluster. In this case a warning is given if any damage or dirty journals are found. The file system should then be unmounted from all nodes in the cluster and fsck.gfs2 should be run manually without the -a or -p options.
This option may not be used with the -n or -y options.
Print more information while running.
This option may not be used with the -n or -p/-a options.