Mounting File Systems
File systems can be mounted from the command line by using the mount command. The commands in Table 14.7 are used from the command line to mount and unmount file systems.
After you create a file system, you need to make it available. You make file systems available by mounting them. Using the mount command, you attach a file system to the system directory tree at the specified mount point, and it becomes available to the system. The root file system is mounted at boot time and cannot be unmounted. Any other file system can be mounted or unmounted from the root file system at any time.
The syntax for mount is as follows:
mount -F <fstype> [generic_options] [ -o specific_options ] [ -O ]
Table 14.8 describes these options.
The following examples illustrate the options described in Table 14.8.
A file system has been created on disk c0t0d0 on slice s0. The directory to be mounted on this disk slice is /home2. To mount the file system, first create the directory called /home2 and then type the following:
mount /dev/dsk/c0t0d0s0 /home2
If the file system has been mounted, you return to a command prompt. No other message is displayed.
In the next example, the -v option is used with the mount command to display a list of all mounted file systems:
mount –v
The system responds with this:
/dev/dsk/c0t0d0s1 on / type ufs read/write/setuid/intr/largefiles/xattr/onerror=panic/dev=2200001 on Fri Jul 19 18:51:42 2002 /dev/dsk/c0t0d0s5 on /usr type ufs read/write/setuid/intr/largefiles/xattr/onerror=panic/dev=2200005 on Fri Jul 19 18:51:43 2002 /proc on /proc type proc read/write/setuid/dev=38c0000 on Fri Jul 19 18:51:41 2002 mnttab on /etc/mnttab type mntfs read/write/setuid/dev=3980000 on Fri Jul 19 18:51:41 2002 fd on /dev/fd type fd read/write/setuid/dev=39c0000 on Fri Jul 19 18:51:44 2002 /dev/dsk/c0t0d0s3 on /var type ufs read/write/setuid/intr/largefiles/xattr/onerror=panic/dev=2200003 on Fri Jul 19 18:51:47 2002 swap on /var/run type tmpfs read/write/setuid/xattr/dev=1 on Fri Jul 19 18:51:48 2002 swap on /tmp type tmpfs read/write/setuid/xattr/dev=2 on Fri Jul 19 18:51:52 2002 /dev/dsk/c0t0d0s7 on /data type ufs read/write/setuid/intr/largefiles/xattr/onerror=panic/dev=2200007 on Fri Jul 19 18:51:52 2002 /dev/dsk/c0t0d0s4 on /opt type ufs read/write/setuid/intr/largefiles/xattr/onerror=panic/dev=2200004 on Fri Jul 19 18:51:52 2002 /dev/dsk/c0t0d0s6 on /export/home type ufs read/write/setuid/intr/largefiles/xattr/onerror=panic/dev= 2200006 on Fri Jul 19 18:51:52 2002
The following example mounts a file system as read-only:
mount -o ro /dev/dsk/c0t0d0s0 /home2
The next example uses the mount command to mount a directory to a file system as read/writeable, disallow setuid execution, and allow the creation of large files:
mount -o rw,nosuid,largefiles /dev/dsk/c0t0d0s0 /home2
Type mount with no options to verify that the file system has been mounted and to review the mount options that were used:
mount
The system responds with information about all mounted file systems, including /home2:
/home2 on /dev/dsk/c0t0d0s0 read/write/nosuid/largefiles on Tue Jul 16 06:56:33 2002
Mounting a File System with Large Files
On a Solaris system, a large file is a regular file whose size is greater than or equal to 2.31GB. A small file is a regular file whose size is less than 2GB. Some utilities can handle large files, and others cannot. A utility is called large file–aware if it can process large files in the same manner that it does small files. A large file–aware utility can handle large files as input and can generate large files as output. The newfs, mkfs, mount, umount, tunefs, labelit, and quota utilities are all large file–aware for UFS file systems.
On the other hand, a utility is called large file–safe if it causes no data loss or corruption when it encounters a large file. A utility that is large file–safe cannot properly process a large file, so it returns an appropriate error. Some examples of utilities that are not large file–aware but are large file–safe include the vi editor and the mailx and lp commands. A full list of commands that are large file–aware and large file–safe can be found in the online manual pages.
The largefiles mount option lets users mount a file system containing files larger than 2GB. The largefiles mount option is the default state for the Solaris 9 environment. The largefiles option means that a file system mounted with this option might contain one or more files larger than 2GB.
You must explicitly use the nolargefiles mount option to disable this behavior. The nolargefiles option provides total compatibility with previous file system behavior, enforcing the 2GB maximum file size limit.
Note
After you mount a file system with the default largefiles option and large files have been created, you cannot remount the file system with the nolargefiles option until you remove any large files and run fsck to reset the state to nolargefiles.
Mounting a File System with UFS Logging Enabled
The UFS logging feature eliminates file system inconsistency, which can significantly reduce the time of system reboots. Use the -o logging option in the /etc/vfstab file or as an option to the mount command to enable UFS logging on a file system.
UFS logging is the process of storing file system operations to a log before the transactions are applied to the file system. Because the file system can never become inconsistent, fsck can usually be bypassed, which reduces the time to reboot a system if it crashes or after an unclean halt.
The UFS log is allocated from free blocks on the file system. It is sized at approximately 1MB per 1GB of file system, up to a maximum of 64MB. The default is nologging.
Note
Is it ever necessary to run fsck on a file system that has UFS logging enabled? The answer is yes. It is usually unnecessary to run fsck on a file system that has UFS logging enabled. The one exception to this is when the log is bad. An example of this is when a media failure causes the log to become unusable. In this case, logging puts the file system in an “error state,” and you cannot mount it and use it until fsck is run. The safest option is to always run fsck. It will bail out immediately if logging is there and the file system is not in an error state.