Mounting File Systems
Explain how to perform mounts and unmounts.
File systems can be mounted from the command line by using the mount command. The commands in Table 1.15 are used from the command line to mount and unmount file systems.
/sbin/mountall is actually a shell script that first checks the state of each file system specified in the /etc/vfstab file before issuing the mount -a command. If the file system flag indicates that the file system is not mountable, mountall will prompt for the root password on the console and try to fix the file system with fsck before running the mount -a command.
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 with few exceptions.
The syntax for mount is as follows:
mount -F <fstype> <options> [ -o <specific_options> ] <-O> device_to_mount mountpoint
Table 1.16 describes options to the mount command.
Determining a File System's Type Because the mount commands need the file system type to function properly, the file system type must be explicitly specified with the -F option or determined by searching the following files:
/etc/vfstabSearch the FS type field for the file system type.
/etc/default/fsSearch for a local file system type.
/etc/dfs/fstypesSearch for a remote file system type.
If the file system type is not found in any of these locations, the system will report an error.
Be very familiar with the mount options for a UFS file system along with the defaults used when an option is not specified. The exam has several questions related to creating and repairing file systems. You need to know all aspects of mounting and unmounting a file system on a production (active) system.
The following examples illustrate the options described in Table 1.16.
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.
When the UFS file system is mounted with no options, a default set of file system specific options are usedthey are explained in Table 1.17. Options specific to the UFS file system are also described in the mount_ufs man pages.
The system responds with this:
# mount -v /dev/dsk/c0t0d0s0 on / type ufs \ read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=2200008 \ on Fri Aug 5 11:32:05 2005 /devices on /devices type devfs read/write/setuid/devices/dev=4380000 \ on Fri Aug 5 11:31:47 2005 ctfs on /system/contract type ctfs \ read/write/setuid/devices/dev=43c0001 on Fri Aug 5 11:31:47 2005 proc on /proc type proc read/write/setuid/devices/dev=4400000 on\ Fri Aug 5 11:31:47 2005 mnttab on /etc/mnttab type mntfs read/write/setuid/devices/dev=4440001 \ on Fri Aug 5 11:31:47 2005 swap on /etc/svc/volatile type tmpfs read/write/setuid/devices/xattr/dev=4480001 \ on Fri Aug 5 11:31:47 2005 objfs on /system/object type objfs read/write/setuid/devices/dev=44c0001 on \ Fri Aug 5 11:31:47 2005 /dev/dsk/c0t0d0s6 on /usr type ufs \ read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=220000e \ on Fri Aug 5 11:32:06 2005 fd on /dev/fd type fd read/write/setuid/devices/dev=4640001 \ on Fri Aug 5 11:32:06 2005 /dev/dsk/c0t0d0s1 on /var type ufs \ read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=2200009 \ on Fri Aug 5 11:32:09 2005 swap on /tmp type tmpfs read/write/setuid/devices/xattr/dev=4480002 \ on Fri Aug 5 11:32:09 2005 swap on /var/run type tmpfs read/write/setuid/devices/xattr/dev=4480003 \ on Fri Aug 5 11:32:09 2005 /dev/dsk/c0t0d0s4 on /data type ufs \ read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=220000c \ on Fri Aug 5 11:32:16 2005 /dev/dsk/c0t0d0s5 on /opt type ufs \ read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=220000d \ on Fri Aug 5 11:32:16 2005 /dev/dsk/c0t0d0s7 on /export/home type ufs \ read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=220000f \ on Fri Aug 5 11:32:16 2005
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:
/home2 on /dev/dsk/c0t0d0s0 read/write/nosuid/largefiles on\ Tue Jul 16 06:56:33 2005
Using SMC to View Current Mounts You can also use the SMC Mounts Tool to view information about mounted file systems. The information provided is similar to the information displayed when you issue the mount command with no options. To access the Mounts Tool, follow the Step by Step procedure for using the SMC Usage Tool described in the section titled "Displaying a File System's Disk Space Usage."
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 2GB. 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 fileaware if it can process large files in the same manner that it does small files. A large fileaware 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 fileaware for UFS file systems.
Due to file system overhead, the largest file size that can be created on a multiterabyte file system is approximately 1 Tbyte. The data capacity of a 1 Tbyte file system is approximately 1 Tbyte minus 0.5% overhead and the recommended 1% free space.
On the other hand, a utility is called large filesafe if it causes no data loss or corruption when it encounters a large file. A utility that is large filesafe cannot properly process a large file, so it returns an appropriate error. Some examples of utilities that are not large fileaware but are large filesafe include the vi editor and the mailx and lp commands. A full list of commands that are large fileaware and large filesafe 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 10 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.
Mounting Largefile File Systems 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. UFS logging is the default in Solaris 10 and does not need to be specified when mounting a file system. Use the nologging option in the /etc/vfstab file or as an option to the mount command to disable 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.
fsck on Logged File Systems 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 quit immediately if logging is there and the file system is not in an error state.