mount_vxfs

NAME

mount_vxfs - mount a VxFS file system

SYNOPSIS

AVAILABILITY

VRTSvxfs VRTSfso (VERITAS File Sharing Option)

DESCRIPTION

The mount command notifies the system that special, a VxFS block special device, is available to users from mount_point, which must exist before mount is invoked. mount_point becomes the name of the root of the newly mounted file system special.

Multiple -o options can be specified only in a comma-separated list.

Only a privileged user can mount file systems.

CLUSTER FILE SYSTEM ISSUES

The mount command reserves a shared volume when invoked. If the shared volume is in use by another command, the mount command will fail.

Use crw, nomtime, and seconly only on cluster-mounted file systems (-o cluster option). crw and seconly determine cluster write and failover capabilities respectively. nomtime provides improved concurrency for applications employing parallel I/O.

The ioerror policy behavior for cluster mounts is different from local mounts. See the ioerror option description for details.

Be careful when accessing shared volumes with other utilities, such as dd, that can write data to disk. It is possible to destroy data being accessed from other nodes.

The delaylog and tmplog options are not supported on cluster file systems.

OPTIONS

generic_options

Supported by the generic mount command. See the mount(1M) manual page.

-F vxfs

Specifies the VxFS file system type.

-o

Specifies the VxFS-specific options in a comma-separated list. The available options are:

blkclear

Clears all data extents before allocating them to a file (requires synchronous zeroing of certain newly allocated extents). This prevents uninitialized data from being present in a file at the time of a system crash.

ckpt=ckpt_name

Mounts the Storage Checkpoint of a VxFS file system. ckpt_name is the name of a file system Storage Checkpoint previously created by the fsckptadm command (see fsckptadm(1M)). mount_point is the directory on which to mount the Storage Checkpoint. special is the Storage Checkpoint pseudo device. Storage Checkpoints are mounted on pseudo devices that do not appear in the system name space. The pseudo devices are created and exist only while the Storage Checkpoint is mounted. A Storage Checkpoint pseudo device name has the following format:

Storage Checkpoints are mounted read-only by default, but you can mount or remount them as writable using the rw option. A file system must be mounted before any of its Storage Checkpoints can be mounted. A file system can be unmounted only after all of its Storage Checkpoints are unmounted.

To mount a Storage Checkpoint in shared mode on a cluster file system, you must also specify the -o cluster option (see EXAMPLES below).

cluster

Mounts a file system in shared mode. special must be a shared volume in a Cluster Volume Manager (CVM) environment. Other nodes in the cluster can also mount special in shared mode. A local mount cannot be remounted in shared mode and shared mount cannot be remounted in local mode.

The first node to mount special is called the primary node. The primary node handles intent logging for the cluster. Other nodes are called secondary nodes. A secondary writable node (rw) is not allowed if the primary node is mounted as read-only (ro).

convosync=direct|dsync|unbuffered|closesync|delay

Alters the caching behavior of the file system for O_SYNC and O_DSYNC I/O operations.

The direct value handles any reads or writes with the O_SYNC or O_DSYNC flags as if the VX_DIRECT caching advisory is set.

The dsync value handles any writes with the O_SYNC flag as if the VX_DSYNC caching advisory is set. It does not modify behavior for writes with O_DSYNC set.

The unbuffered value handles any reads or writes with the O_SYNC or O_DSYNC flags as if the VX_UNBUFFERED caching advisory is set.

The closesync value delays O_SYNC or O_DSYNC writes so that they do not take effect immediately.

If the closesync, dsync, direct, or unbuffered value is set and a file is written to using a file descriptor with the O_SYNC or O_DSYNC flag set, the equivalent of an fdatasync(2) call is performed on the final close of the descriptor.

The delay value delays O_SYNC or O_DSYNC writes so that they do not take effect immediately. With this option, VxFS changes O_SYNC or O_DSYNC writes into delayed writes. No special action is performed when closing a file. This option effectively cancels data integrity guarantees typically provided by opening a file with O_SYNC or O_DSYNC.

crw

The cluster read-write option allows asymmetric mounts, that is, you can mount a specified cluster file system in read-only or read-write mode independently of the other shared file system nodes. crw must be specified with the -o cluster option. Without specifying crw, the default functionality of the cluster mount is retained; the read-write capability of cluster secondaries are the same as the cluster primary. You can use the crw in conjunction with rw or ro as shown in the following mount compatibility matrix:

If the primary is mounted with ro,crw, or rw,crw as shown in the first column, the secondary read and write capabilities can still be set independently. For a cluster mount, rw on the primary enables cluster-wide read-write capability.

The read and write capabilities can be changed from its original setting to another using the -o remount option. The read and write capabilities can be changed according to the following matrix:

If a cluster file system is mounted read-write (rw), the underlying disk group must have the activation mode attribute set to sharedwrite (sw).

If a cluster file system is mounted ro,crw, and the disk group activation mode is sharedread (sr), that cluster file system can never be a primary, and must be mounted seconly (see the seconly option below). See the VERITAS Storage Foundation Cluster File System Installation and Administration Guide and the Volume Manager vxdg manual page for more information on disk activation modes.

datainlog | nodatainlog

Generally, VxFS does O_SYNC or O_DSYNC writes by logging the data and the time change to the inode (datainlog). If the nodatainlog option is used, the logging of synchronous writes is disabled; O_SYNC writes the data into the file and updates the inode synchronously before returning to the user.

ioerror=disable| nodisable | wdisable | mwdisable

Sets the policy for handling I/O errors on a mounted file system. Multiple error policies were implemented in VxFS to handle evolving storage technologies for which a single approach is no longer adequate. mwdisable is the default ioerror mount option for local mounts. disable is the default ioerror mount option for cluster mounts.

I/O errors can occur while reading or writing file data, or while reading or writing metadata. The file system can respond to these I/O errors either by halting or by gradually degrading. ioerror provides four policies that determine how the file system responds to the various errors. All four policies limit data corruption, either by stopping the file system or by marking a corrupted inode as bad.

The following matrix shows how the file system responds to the various errors depending on the policy set:

If disable is selected, VxFS disables the file system after detecting any I/O error. You must then unmount the file system and correct the condition causing the I/O error. After the problem is repaired, run fsck and mount the file system again. In most cases, replay fsck is sufficient to repair the file system. A full fsck is required only in cases of structural damage to the file system's metadata. Select disable in environments where the underlying storage is redundant, such as RAID-5 or mirrored disks.

If nodisable is selected, when VxFS detects an I/O error, it takes steps (sets the appropriate error flags), to contain the error, but continues running. Note that the "degraded" condition indicates possible data or metadata corruption, not the overall performance of the file system.

For file data read and write errors, VxFS sets the VX_DATAIOERR flag in the super-block. For metadata read errors, VxFS sets the VX_FULLFSCK flag in the super-block. For metadata write errors, VxFS sets the VX_FULLFSCK and VX_METAIOERR flags in the super-block and may mark associated metadata as bad on disk. VxFS then prints the appropriate error messages to the console (see the VERITAS File System Administrator's Guide for information on what actions to take for specific errors).

You should stop the file system as soon as possible and repair the condition causing the I/O error. After the problem is repaired, run fsck and mount the file system again.

Select nodisable if you want to implement the policy that most closely resembles the previous VxFS error handling policy.

If wdisable (write disable) or mwdisable (metadata-write disable) is selected, the file system is disabled or degraded, as shown in the matrix, depending on the type of error encountered. Select wdisable or mwdisable for environments where read errors are more likely to persist than write errors, such as when using non-redundant storage.

Behavior on cluster file systems is somewhat different. If the policy selected is disable, the file system is disabled only on the node where the I/O error occurs. The file system is still accessible from the other nodes. If the I/O error is on the CFS primary, a new primary is elected from the remaining nodes and the original primary becomes a secondary.

disable is the recommended policy for cluster file systems. With any other policy, a metadata I/O error can mark the file system for a full file system check. If the CFS primary subsequently fails, the other nodes in the cluster cannot take over the primaryship, thereby disabling access to the file system from all nodes in the cluster. Note: If the CVM disk detach policy (the way unusable disks in a shared disk group are detached) is local, the I/O error policy must be disable.

fso

Enables VERITAS File Sharing Option (FSO) functionality on the specified file system. The fso option is available only if the VERITAS VRTSfso package is installed. See the FSO documentation set that is installed with the FSO package for information on product operation.

largefiles | nolargefiles

These options do not turn largefiles capability on and off (use mkfs or fsadm to set and clear the largefiles flag), but they do verify whether a file system is largefiles capable. If nolargefiles is specified and the mount succeeds, the file system does not contain any files two gigabytes or larger, and such files cannot be created. If largefiles is specified and the mount succeeds, the file system can contain files two gigabytes or larger, and large files can be created. For a mount to succeed, the option must match the largefiles flag as specified by mkfs or fsadm.

log | delaylog | tmplog

Controls the timing of flushing the VxFS intent log and other metadata to disk, which affects when operations are guaranteed persistent after a system failure. The default is delaylog.

In the following description, the term "effects of system calls" refers to changes to file system data and metadata caused by the system call, excluding changes to st_atime (see the stat(2) manual page).

In log mode, all system calls other than write(2), writev(2), and pwrite(2) are guaranteed to be persistent once the system call returns to the application.

In delaylog mode, the effects of most system calls other than write(2), writev(2), and pwrite(2) are guaranteed to be persistent approximately 3 seconds after the system call returns to the application. Contrast this with the behavior of most other file systems in which most system calls are not persistent until approximately 30 seconds or more after the call has returned.

In tmplog mode, the effects of system calls have persistence guarantees that are similar to those in delaylog mode. In addition, enhanced flushing of delayed extending writes is disabled, which results in better performance but increases the chances of data being lost or unitialized data appearing in a file that was being actively written at the time of a system failure. This mode is only recommended for temporary file systems.

In delaylog and log mode, the rename(2) system call flushes the source file to disk to guarantee the persistence of the file data before renaming it. In both modes, the rename is also guaranteed to be persistent when the system call returns. This benefits shell scripts and programs that try to update a file atomically by writing the new file contents to a temporary file and then renaming it on top of the target file.

In all cases, VxFS is fully POSIX compliant. The effects of the fsync(2) and fdatasync(2) system calls are guaranteed to be persistent once the calls return. The persistence guarantees for data or metadata modified by write(2), writev(2), or pwrite(2) are not affected by the logging mount options. The effects of these system calls are guaranteed to be persistent only if the O_SYNC, O_DSYNC, VX_DSYNC, or VX_DIRECT flag, as modified by the convosync= mount option, has been specified for the file descriptor.

The behavior of NFS servers on a VxFS file system is unaffected by the log, delaylog, and tmplog mount options. In all cases, VxFS complies with the persistency requirements of the NFS v2 and NFS v3 standard.

logiosize=size

The performance of some storage devices (specifically, devices using the read-modify-write feature) improves if the writes are issued in one or more multiples of a particular size. When a file system is mounted with the logiosize option, VxFS writes the intent log in at least size bytes, or a multiple of size bytes, to obtain the maximum performance from such devices. The values for size can be 1024, 2048, or 4096. The default value is the sector size of the device. The logiosize option is supported only on local mounts.

mand

Honor mandatory locking. Without this option, only advisory locking is performed even if mandatory locking was enabled on a specific file, which is done by setting the set-group-id bit and clearing the group execute bit in the file's mode.

mincache=direct|dsync|unbuffered|closesync|tmpcache

Alters the caching behavior of the file system.

The direct value handles any reads without the O_SYNC flag, or any writes without the O_SYNC flag, VX_DSYNC, VX_DIRECT, and VX_UNBUFFERED caching advisories, as if the VX_DIRECT caching advisory was set.

The unbuffered value handles any reads without the O_SYNC flag, or any writes without the O_SYNC flag, VX_DSYNC, VX_DIRECT, and VX_UNBUFFERED caching advisories, as if the VX_UNBUFFERED caching advisory was set.

The dsync value handles any writes without the O_SYNC flag, or one of the VX_DIRECT, VX_DSYNC, and VX_UNBUFFERED caching advisories, as if the VX_DSYNC caching advisory was set.

For the closesync, dsync, unbuffered, and direct values, when the final close of a file descriptor referencing a file is performed, the equivalent of an fdatasync(2) call is performed.

The tmpcache value disables delayed extending writes, trading off integrity for performance. If blkclear is used in conjunction with tmpcache, newly allocated extents are not zeroed. If the system crashes, uninitialized data may appear in files that were being written at the time of a system crash.

See vxfsio(7) for an explanation of VX_DIRECT, VX_DSYNC, and VX_UNBUFFERED.

noatime

Directs the file system to ignore file access time updates except when they coincide with updates to ctime or mtime (see the stat(2)) manual page. By default, the file system is mounted with access time (atime) recording. You can use the noatime option to reduce disk activity on file systems where access times are not important.

noauto

Allows the file system to be mounted explicitly. That is, the -a option will not cause the file system to be mounted. This option is normally used for filesystems listed in /etc/fstab file, which should not be mounted automatically at boot time.

nomtime

The nomtime option is for distributed applications that read and write to the same file simultaneously from one or more cluster nodes. nomtime delays updating the file modification time in the specified cluster file system. Updating file modification and change times are not synchronized within the cluster, which eliminates serializing two updates and improves concurrency. Use this option in high-performance computing (HPC) environments when an application does not require consistent, cluster-wide file modification times. The nomtime option operates only on cluster mounted file systems (-o cluster option). See the VERITAS Storage Foundation Cluster File System Installation and Administration Guide for more information on parallel I/O.

qio | noqio

Enables or disables the VERITAS Quick I/O for Databases option for the given file system. Quick I/O is available as a licensed feature of VxFS. By default, mount enables Quick I/O on the file system. If Quick I/O is not available, mount mounts the file system without Quick I/O. If qio is specified, but the feature is not licensed, mount prints an error message and terminates without mounting the file system. If noqio is specified, mount disables Quick I/O even if the license is installed.

For cluster file systems, qio is also the default if a Quick I/O license is present.

qlog=[special]

Enables the file system to use VERITAS QuickLog. QuickLog threads multiple file system logs together and redirects the file system log writes to the special device. If special is not specified, the file system selects one of the QuickLog special devices. This option improves the performance of NFS servers. See the qlogmk(1M) manual page for more information on creating a QuickLog volume.

The qlog= option was formerly the vxldlog= option, and is functionally identical.

quota

Enables disk quotas. The quota option is valid only on file systems that are mounted read/write (rw).

To turn on user quotas, there must be a file named quotas owned by root in the file system root directory. If this file does not exist, a quotas file is created. The quotas file stores usage limits for each user.

VxFS maintains quota information in a private area of the file system. If the file system is mounted with quotas enabled, and the file system was previously mounted with quotas disabled and was modified, the quota information is rebuilt. This may take awhile depending on the amount of information to rebuild. See edquota(1M) for details on how to create and modify usage limits in the quotas file.

remount

Changes the mount options for a mounted file system. In particular, remount changes the logging and caching policies. It also changes a file system from read-only to read/write.

remount cannot change a file system from read/write to read-only, nor can it set the snapof or snapsize attributes.

rw | ro

Read-write or read-only. The default is rw.

seconly

Mounts a shared file system as a secondary only. A secondary-only file system cannot assume the primaryship for the specified shared file system. For a mount with the seconly option to succeed, primary must already be mounted. seconly must be specified with the -o cluster option. The seconly option overrides any policy that was set using the fsclustadm command (see the fsclustadm(1M) manual page). This option can be set or reset using the -o remount option. A remount with seconly fails if the file system node is already the primary for the file system.

snapof=filesystem

Mounts the file system as a snapshot of filesystem, where filesystem is either the directory on which a VxFS file system is mounted, or the block special file containing a mounted VxFS file system.

On cluster file systems, snapshots can be created on any node in the cluster, and backup operations can be performed from that node. The snapshot of a cluster file system is accessible only on the node where it is created, that is, the snapshot file system itself cannot be cluster mounted. See the VERITAS Storage Foundation Cluster File System Installation and Administration Guide for details on creating snapshots on cluster file systems.

snapsize=size

Used in conjunction with snapof. size is the size in sectors of the snapshot file system being mounted. This option is required only when the device driver cannot determine the size of snapof_special, and defaults to the entire device if not specified.

suid | nosuid

setuid is honored or ignored on execution. The default is suid.

tranflush

When VxFS is the default boot file system (/stand) on HP-UX, there can be no intent log replay during the initial stages of the boot process. To ensure data and metadata consistency during the boot process, the tranflush option flushes all metadata updates to disk before returning from a system call. The tranflush option therefore enables VxFS to approximate the behavior of a file system with no intent logging functionality. The tranflush option automatically enables the blkclear and log options. It is advisable to specify the mincache=dsync mount option with tranflush. tranflush must be explicitly specified when remounting the file system.

The tmplog, delaylog, and datainlog mount options do not operate with tranflush. The tranflush option does not operate on read-only file systems or cluster file systems.

EXAMPLES

To mount a Storage Checkpoint of a file system, first mount the file system, then mount the Storage Checkpoint:

To unmount a file system, unmount the Storage Checkpoint first:

To mount a Storage Checkpoint of a cluster file system on a VERITAS Volume Manager volume:

To have Storage Checkpoints mounted automatically when the system reboots, you can list them in the /etc/fstab file as in the following example:

FILES

/etc/mnttab

Table of mounted file systems.

SEE ALSO

qiomkfile (1), edquota(1M), fsadm_vxfs (1M), fsck_vxfs (1M), fsckptadm (1M), fsclustadm (1M), mkfs_vxfs (1M), mount(1M), qlogmk(1M), setmnt(1M), vxdg(1M), vxumount(1M), fdatasync(2), fsync(2), setuid(2), stat(2), fstab(4), fs_vxfs (4), mnttab(4), vxfsio (7)

VERITAS File System Administrator's Guide,
VERITAS File System Release Notes,
VERITAS Storage Foundation Cluster File System Installation and Administration Guide