If a file system is damaged and its consistency is lost, for example, due to an automatic recovery error after a primary MDS failure, the file system must be checked and restored using sfcfsck(8).
The GFS Shared File System provides the update log function to ensure high-speed recovery if an error such as a system failure occurs. If the update log function has been enabled, the file system can be repaired quickly regardless of the size of the file system. This is possible because of update log replay, which updates the un-updated portion of the meta-data located in the update log area.
By default, or when "-o log" is specified, sfcfsck(8) repairs the file system by replaying the update log.
If the update log data has been physically damaged, sfcfsck(8) does not execute update log replay, but automatically performs a full check on the file system. To meet the need for immediate system operation resuming, an option "-o elog" that avoids file system restoration while it provides update log replay. If this option is specified, sfcfsck(8) terminates immediately without performing check and recovery when the update log data has been physically damaged. In this event, the file system cannot be mounted unless check and recovery is performed using sfcfsck(8). The mounting on such a file system should be attempted after it is restored through full checking without update log replay by the "-o nolog" option.
The following example repairs a file system with log replay.
# sfcfsck /dev/sfdsk/gfs01/dsk/volume01 <Enter> |
The following example performs a full check on the file system and repairs it without log replay.
# sfcfsck -o nolog /dev/sfdsk/gfs01/dsk/volume01 <Enter> |
See
For details about sfcfsck(8) options, see sfcfsck(8) in this manual.
