Before you can mount a GFS file system, the file system must exist (refer to Section 4.1, “Creating a File System”
), the volume where the file system exists must be activated, and the supporting clustering and locking systems must be started (refer to Chapter 3, Getting Started
and Configuring and Managing a Red Hat Cluster
. After those requirements have been met, you can mount the GFS file system as you would any Linux file system.
To manipulate file ACLs, you must mount the file system with the
mount option. If a file system is mounted without the
mount option, users are allowed to view ACLs (with
getfacl), but are not allowed to set them (with
Mounting Without ACL Manipulation
Mounting With ACL Manipulation
mount -o acl
GFS-specific option to allow manipulating file ACLs.
Specifies the block device where the GFS file system resides.
Specifies the directory where the GFS file system should be mounted.
In this example, the GFS file system on
/dev/vg01/lvol0 is mounted on the
mount /dev/vg01/lvol0 /mydata1
BlockDevice MountPoint -o
argument consists of GFS-specific options (refer to Table 4.2, “GFS-Specific Mount Options”
) or acceptable standard Linux
options, or a combination of both. Multiple
parameters are separated by a comma and no spaces.
mount command is a Linux system command. In addition to using GFS-specific options described in this section, you can use other, standard,
mount command options (for example,
-r). For information about other Linux
mount command options, see the Linux
mount man page.
This table includes descriptions of options that are used with local file systems only For the Red Hat Enterprise Linux 5.5 release and later Red Hat does not support the use of GFS as a single-node file system. Red Hat will continue to support single-node GFS file systems for existing customers.
Table 4.2. GFS-Specific Mount Options
|Allows manipulating file ACLs. If a file system is mounted without the |
acl mount option, users are allowed to view ACLs (with
getfacl), but are not allowed to set them (with
|Caution: This option should not be used when GFS file systems are shared.||Forces GFS to treat the file system as a multihost file system. By default, using |
lock_nolock automatically turns on the
|Caution: This option should not be used when GFS file systems are shared.||Tells GFS that it is running as a local file system. GFS can then turn on selected optimization capabilities that are not available when running in cluster mode. The |
localcaching flag is automatically turned on by
|Caution: This option should not be used when GFS file systems are shared.|| |
| Tells GFS to let the VFS (virtual file system) layer do all flock and fcntl. The |
localflocks flag is automatically turned on by
| Note that the |
localflocks mount option affects only advisory
fcntl()/POSIX locks and
flock locks that are issued by applications. The internal locking that ensures coherency of data across the cluster by means of GFS's
glock abstraction is separate from and not affected by the
| If you are unsure whether an application uses |
fcntl()/POSIX locks and thus requires that you mount your file system with the
localflocks, you can use the
strace utility to print out the system calls that are made during a test run of the application. Look for
fcntl calls that have
F_SETLKW as the
| Note that GFS does not currently support either leases or mandatory locking. |
|Allows the user to specify which locking protocol to use with the file system. If |
LockModuleName is not specified, the locking protocol name is read from the file system superblock.
|For a clustered file system, allows the user to specify which locking table to use with the file system.|
This option allows a GFS node to not panic when an oops occurs. (By default, a GFS node panics when an oops occurs, causing the file system used by that node to stall for other GFS nodes.) A GFS node not panicking when an oops occurs minimizes the failure on other GFS nodes using the file system that the failed node is using. There may be circumstances where you do not want to use this option — for example, when you need more detailed troubleshooting information. Use this option with care.
Note: This option is turned on automatically if
lock_nolock locking is specified; however, you can override it by using the
|Upgrade the on-disk format of the file system so that it can be used by newer versions of GFS.|
errors=panic is specified, file system errors will cause a kernel panic. The default behavior, which is the same as specifying
errors=withdraw, is for the system to withdraw from the file system and make it inaccessible until the next reboot; in some cases the system may remain running. For information on the GFS withdraw function, see Section 4.16, “The GFS Withdraw Function”.