Using the mount Command

Using the `mount` Command

The following examples show different scenario:

In NFS Version 2 or NFS Version 3, both of the following commands mount an NFS file system from the server bee read-only.
```
# mount -F nfs -r bee:/export/share/man /usr/man
```
```
# mount -F nfs -o ro bee:/export/share/man /usr/man
```
In NFS Version 4, the following command line would accomplish the same mount.
```
# mount -F nfs -o vers=4 -r bee:/export/share/man /usr/man
```
In NFS Version 2 or NFS Version 3, the -O option in the following command forces the man pages from the server bee to be mounted on the local system even if /usr/man has already been mounted.
```
# mount -F nfs -O bee:/export/share/man /usr/man
```
In NFS Version 4, the following command would accomplish the same mount:
```
# mount -F nfs -o vers=4 -O bee:/export/share/man /usr/man
```
In NFS Version 2 or NFS Version 3, the following command uses client failover.
```
# mount -F nfs -r bee,wasp:/export/share/man /usr/man
```
In NFS Version 4, the following command uses client failover.
```
# mount -F nfs -o vers=4 -r bee,wasp:/export/share/man /usr/man
```
Note:
When used from the command line, the listed servers must support the same version of the NFS protocol. Do not use different NFS Version servers when running mount from the command line. You can use the servers with autofs because autofs automatically selects the best subset of the NFS Version servers.
The following example shows how to use an NFS URL with the mount command in NFS Version 2 or NFS Version 3.
```
# mount -F nfs nfs://bee//export/share/man /usr/man
```
The following example shows how to use an NFS URL with the mount command in NFS Version 4.
```
# mount -F nfs -o vers=4 nfs://bee//export/share/man /usr/man
```
The following example shows how to use the quota mount option to enable the user to check the file system disk quota and usage.
```
# mount -F nfs -o quota bee:/export/share/man /usr/man
```
The following example shows how to use the forcedirectio mount option to enable the client to permit concurrent writes, as well as concurrent reads and writes, to a file.
```
# mount -F nfs -o forcedirectio bee:/home/somebody /mnt
```
In this example, the command mounts an NFS file system from the server bee and enables concurrent reads and writes for each file in the directory /mnt. When support for concurrent reads and writes is enabled, the following occurs.
- The client permits applications to write to a file in parallel.
- Caching is disabled on the client. Consequently, data from reads and writes is kept on the server. More explicitly, because the client does not cache the data that is read or written, any data that the application does not already have cached for itself is read from the server. The client's operating system does not have a copy of this data. Normally, the NFS client caches data in the kernel for applications to use.
  
  Because caching is disabled on the client, the read-ahead and write-behind processes are disabled. A read-ahead process occurs when the kernel anticipates the data that an application might request next. The kernel then starts the process of gathering that data in advance. The kernel's goal is to have the data ready before the application makes a request for the data.
  
  The client uses the write-behind process to increase write throughput. Instead of immediately starting an I/O operation every time an application writes data to a file, the data is cached in memory. Later, the data is written to the disk.
  
  Potentially, the write-behind process permits the data to be written in larger chunks or to be written asynchronously from the application. Typically, the result of using larger chunks is increased throughput. Asynchronous writes permit overlap between application processing and I/O processing. Also, asynchronous writes permit the storage subsystem to optimize the I/O by providing a better sequencing of the I/O. Synchronous writes force a sequence of I/O on the storage subsystem that might not be optimal.
- Significant performance degradation can occur if the application is not prepared to handle the semantics of data that is not being cached. Multithreaded applications avoid this problem.
Note:
If support for concurrent writes is not enabled, all write requests are serialized. When a write request is in progress, a second write request has to wait for the first write request to be completed before proceeding.

The following example shows how to use the mount command with no arguments to display file systems that are mounted on a client.

$ mount
/ on /dev/dsk/c0t3d0s0 read/write/setuid on Wed Apr 7 13:20:47 2004
/usr on /dev/dsk/c0t3d0s6 read/write/setuid on Wed Apr 7 13:20:47 20041995
/proc on /proc read/write/setuid on Wed Apr 7 13:20:47 2004
/dev/fd on fd read/write/setuid on Wed Apr 7 13:20:47 2004
/tmp on swap read/write on Wed Apr 7 13:20:51 2004
/opt on /dev/dsk/c0t3d0s5 setuid/read/write on Wed Apr 7 13:20:51 20041995
/home/kathys on bee:/export/home/bee7/kathys              
  intr/noquota/nosuid/remote on Wed Apr 24 13:22:13 2004