Types of File Systems

The system software supports three types of file systems:

• Disk-based
• Network-based
• Pseudo

Disk-Based File Systems

Disk-based file systems are stored on physical media such as hard disks, CD-ROMs, and diskettes. Disk-based file systems can be written in different formats. The available formats are:

• UFS - UNIX^(R) file system (based on the BSD Fat Fast File system that was provided in the 4.3 Tahoe release). UFS is the default disk-based file system in SunOS system software.
• HSFS - High Sierra and ISO 9660 file system. High Sierra is the first CD-ROM file system; ISO 9660 is the official standard version of the High Sierra File System. The HSFS file system is used on CD-ROM, and is a read-only file system. SunOS HSFS supports Rock Ridge extensions to ISO 9660, which, when present on a CD-ROM, provide all UFS file system semantics and file types except for writability and hard links.
• PCFS - PC file system, which allows read/write access to data and programs on DOS-formatted disks written for DOS-based personal computers.

Each type of disk-based file system is customarily associated with a particular media device:

• UFS with hard disk
• HSFS with CD-ROM
• PCFS with diskette
• s5 with hard disk

These associations are not, however, restrictive. For example, CD-ROMs and diskettes can have UFS file systems put on them.

Network-Based File Systems

Network-based file systems are file systems accessed over the network. Typically, network-based file systems are file systems that reside on one system and are accessed by other systems across the network. NFS is the only available network-based file system.

NFS is the default SunOS distributed file system. You administer distributed file systems by exporting them from a server and mounting them on individual systems. See "Making File Systems Available" on page 21 for more information.

Pseudo File Systems

Pseudo file systems are virtual or memory-based file systems that provide access to special kernel information and facilities. Most pseudo file systems do not use file system disk space. Cache File Systems use a file system to contain the cache. Some pseudo file systems, such as the temporary file system, may use the swap space on a physical disk.

The Cache File System (CacheFS)

The Cache File System can be used to improve performance of remote file systems or slow devices such as CD-ROM. When a file system is cached, the data read from the remote file system or CD-ROM is stored in a cache on the local system. See Chapter 5, "The Cache File System," for detailed information on setting up and administering Cache File Systems.

The Temporary File System (TMPFS)

The TMPFS file system uses local memory for file system reads and writes. Access to files in a TMPFS file system is typically much faster than to files in a UFS file system. Files in the temporary file system are not permanent. They are deleted when the file system is unmounted and when the system is shut down or rebooted.

TMPFS is the default file system type for the /tmp directory in the SunOS system software. You can copy or move files into or out of the /tmp directory, just as you would in a UFS /tmp file system.

Using TMPFS file systems can improve system performance by saving the cost of reading and writing temporary files to a local disk or across the network. For example, temporary files are created when you compile a program. The operating system generates a lot of disk or network activity while manipulating these files. Using TMPFS to hold these temporary files may significantly speed up their creation, manipulation, and deletion.

The TMPFS file system uses swap space as a temporary backing store. If a system with a TMPFS file system does not have adequate swap space, two problems can occur:

• The TMPFS file system can run out of space, just as a regular file system can fill up.

• Because TMPFS allocates swap space to save file data (if necessary), some programs may not be able to execute because there is not enough swap space.

See Chapter 2, "Creating File Systems," for information on how to create TMPFS file systems. See Chapter 9, "Configuring Additional Swap Space," for information about increasing swap space.

The Loopback File System (LOFS)

The LOFS file system lets you create a new virtual file system. You can access files using an alternative path name. For example, you can create a loopback mount of / onto /tmp/newroot. The entire file system hierarchy looks like it is duplicated under /tmp/newroot, including any file systems mounted from NFS servers. All files are accessible either with a path name starting from /, or with a path name starting from /tmp/newroot.

See Chapter 2, "Creating File Systems," for information on how to create LOFS file systems.

The Process File System (PROCFS)

The PROCFS file system resides in memory. It contains a list of active processes, by process number, in the /proc directory. Information in the /proc directory is used by commands like ps. Debuggers and other

development tools can also access the address space of the processes using file system calls. The following example shows a partial listing of the contents of the /proc directory:

jupiter% ls -l /proc total 144944 -rw------- 1 root root 0 Dec 19 15:45 00000 -rw------- 1 root root 196608 Dec 19 15:45 00001 -rw------- 1 root root 0 Dec 19 15:45 00002 -rw------- 1 root root 1028096 Dec 19 15:46 00073 -rw------- 1 root root 1445888 Dec 19 15:46 00091 -rw------- 1 root root 1142784 Dec 19 15:46 00093 -rw------- 1 root root 1142784 Dec 19 15:46 00095 -rw------- 1 ignatz staff 1576960 Dec 19 15:50 00226 -rw------- 1 ignatz staff 192512 Dec 19 15:51 00236 -rw------- 1 ignatz staff 1269760 Dec 19 15:52 00240 -rw------- 1 ignatz staff 6090752 Dec 19 15:52 00241 -rw------- 1 ignatz staff 188416 Dec 19 15:52 00247 -rw------- 1 ignatz staff 2744320 Dec 19 15:52 00256

---

Caution - Do not delete the files in the /proc directory. Deleting processes from the /proc directory is not the recommended way to kill them. Remember, /proc files do not use disk space, so there is little reason to delete files from this directory.

---

The /proc directory does not require system administration.

Additional Pseudo File Systems

These additional types of pseudo file systems are listed for your information. They do not require administration.

• FIFOFS (first-in first-out) - Named pipe files that give processes common access to data
• FDFS (file descriptors) - Provides explicit names for opening files using file descriptors
• NAMEFS - Used mostly by STREAMS for dynamic mounts of file descriptors on top of files

• SPECFS (special) - Provides access to character special and block devices
• SWAPFS - File system used by the kernel for swapping

File System Administration Commands

Most file system administration commands have a generic and a file system- specific component. Use the generic commands, which call the file system- specific component. Table 1-1 lists the generic file system administrative commands, which are located in the /usr/bin directory.

Table 1-1

Command	Description
clri(1M)	Clears inodes
df(1M)	Reports the number of free disk blocks and files
ff(1M)	Lists file names and statistics for a file system
fsck(1M)	Checks the integrity of a file system and repairs any damage found
fsdb(1M)	File system debugger
fstyp(1M)	Determines the file system type
labelit(1M)	Lists or provides labels for file systems when copied to tape (for use by the volcopy command only)
mkfs(1M)	Makes a new file system
mount(1M)	Mounts file systems and remote resources
mountall(1M)	Mounts all file systems specified in a file system table
ncheck(1M)	Generates a list of path names with their i-numbers
umount(1M)	Unmounts file systems and remote resources
umountall(1M)	Unmounts all file systems specified in a file system table
volcopy(1M)	Makes an image copy of a file system

Most of these commands also have a file system-specific counterpart.

---

Caution - If you specify an operation on a file system that does not support it, the generic command displays this error message:

command: Operation not applicable for FSType type

---

Syntax of Generic Commands

Most of these commands use this syntax: command [-F type] [-V] [generic-options] [-o specific-options] [special|mount-point] [operands]

The options and arguments to the generic commands are:

-F type Specifies the type of file system. If you do not use this option, the command looks for an entry which matches special or mount point in the /etc/vfstab file. Otherwise, the default is taken from the file /etc/default/fs for local file systems and from the file /etc/dfs/fstypes for remote file systems.

-V

Echoes the completed command line. The echoed line may include additional information derived from /etc/vfstab. Use this option to verify and validate the command line. The command is not executed.

generic-options

Options common to different types of file systems.

-o specific-options A list of options specific to the type of file system. The list must have the following format: -o followed by a space, followed by a series of keyword [=value] pairs separated by commas with no intervening spaces.

special|mount-point Identifies the file system. The name must be either the mount point or the special device file for the slice holding the file system. For some commands, the special file must be the raw (character) device and for other commands it must be the block device. See "Understanding Disk Device Names" on page 13 for more information about disk device names. In some cases, this argument is used as a key to search the file /etc/vfstab for a matching entry from which to obtain other information. In most cases, this argument is required and must come immediately after specific-options. However, it is not required when you want a command to act on all the file systems (optionally limited by type) listed in the /etc/vfstab file.

operands

Arguments specific to a type of file system. See the specific manual page of the command (for example, mkfs_ufs(1M)) for a detailed description.

Manual Pages for Generic and Specific Commands

Both the generic and specific commands have manual pages in the man Pages(1M): System Administration Commands. The specific manual page is a continuation of the generic manual page. To look at a specific manual page, append an underscore and the file system type abbreviation to the generic command name. For example, to see the specific manual page for mounting an HSFS file system, type man mount_hsfs(1M).

How the File System Commands Determine the File System Type

The generic file system commands determine the file system type by following this sequence:

1. From -F, if supplied.

2. By matching a special device with an entry in /etc/vfstab (if special is supplied). For example, fsck first looks for a match against the fsck device field; if no match is found, it then checks against the special device field.

3. By using the default specified in /etc/default/fs for local file systems and in /etc/dfs/fstypes for remote file systems.

How to Find Out the Type of a File System

You can determine the type of a file system from the same files the generic commands use:

• The FS type field in the file system table (/etc/vfstab)
• The /etc/default/fs file for local file systems
• The /etc/dfs/fstypes file for remote file systems

To find a file system's type in the /etc/vfstab file:

* Type grep mount-point /etc/vfstab and press Return. Information for the mount point is displayed.

mars% grep /tmp /etc/vfstab swap - /tmp tmpfs - yes - mars%

If vfstab does not have an entry for a file system, use one of the following procedures to determine the file system's type.

To identify a mounted file system's type:

* Type grep mount-point /etc/mnttab and press Return. Information on the mount point is displayed.

mars% grep /home /etc/mnttab mars:(pid129) /home nfs ro,ignore,map=/etc/auto_home,indirect,dev=21c0004 693606637 neptune:/export/home/neptune /tmp_mnt/home/neptune nfs rw,dev=21c0005 695409833 mars%

Or

* Type mount and press Return. A list of the mounted file systems and their types is displayed.

mars% mount / on /dev/dsk/c0t3d0s0 read/write on Tue Dec 24 12:29:22 1993 /usr on /dev/dsk/c0t1d0s6 read/write on Tue Dec 24 12:29:22 1993 /proc on /proc read/write on Tue Dec 24 12:29:22 1991 /usr/man on swsvr4-50:/export/svr4/man read/write/remote on Mon Dec 30 12:49:11 1993 /usr/openwin on swsvr4-50:/export/svr4/openwinV3.jpb1 read/write/remote on Mon Dec 30 \ 13:50:54 1993 /tmp on swap read/write on Wed Jan 8 13:38:45 1994 /mnt on swsvr4-50:/export/svr4 read/write/remote on Fri Jan 10 15:51:23 1994 /tmp_mnt/home/neptune on neptune:/export/home/neptune read/write/remote on Tue Jan 14 \ 09:23:53 1994 mars%

Or

1. Type devnm mount-point and press Return.

   The raw device name is displayed.

2. Become superuser.

3. Type fstyp /dev/rdsk/cntndnsn and press Return. The type of the file system is displayed.

mars% devnm /usr /dev/dsk/c0t1d0s6 /usr mars% su Password: # fstyp /dev/rdsk/c0t3d0s0 ufs #

The Default SunOS File Systems

The SunOS file system is hierarchical, starting with the root directory (/) and continuing downwards through a number of directories. The system software installs a default set of directories and uses a set of conventions to group similar types of files together. Table 1-2 describes the default SunOS file systems, and shows the type of each file system.

Table 1-2

File System or Directory	File System Type	Description
/	UFS	The top of the hierarchical file tree. The root directory contains the directories and files critical for system operation, such as the kernel (/kernel/unix), the device drivers, and the programs used to start (boot) the system. It also contains the mount point directories where local and remote file systems can be attached to the file tree.
/usr	UFS	Contains system files and directories that can be shared with other users. Files that run only on certain types of systems are in the /usr directory (for example SPARC(R) executables). Files (such as manual pages) that can be used on all types of systems are in /usr/share.
/export/home or /home	NFS, UFS	The mount point for users' home directories, which store users' work files. By default /home is an automounted file system. On standalone systems, /home may be a UFS file system on a local disk slice.
/var	UFS	Contains system files and directories that are likely to change or grow over the life of the local system. These include system logs, vi and ex backup files, and uucp files.

Table 1-2 (Continued)

File System or Directory	File System Type	Description
/opt	NFS, UFS	Mount point for optional, third-party software. On some systems /opt may be a UFS file system on a local disk slice.
/tmp	TMPFS	Temporary files, cleared each time the system is booted or unmounted.
/proc	PROCFS	Contains a list of active processes, by number.

The root (/) and /usr file systems are both needed to run a system. Some of the most basic commands from the /usr file system (like mount) are included in the root file system so that they are available when the system boots or is in single-user mode and /usr is not mounted. See Appendix A, "File System Reference," for a complete list of the default directories.

Understanding Disk Device Names

Please refer to the Administration Supplement for Solaris Platforms for a description of device naming conventions.

Understanding the UFS File System

UFS is the default disk-based file system in SunOS system software. Most of the time, when you administer a disk-based file system, you will be administering UFS. It provides the following features:

• State flags - Show the state of the file system: clean, stable, active, or unknown. These flags eliminate unnecessary file system checks. If the file system is "clean" or "stable," fsck is not run.
• Extended fundamental types (EFT) - 32-bit user ID (UID), group ID (GID), and device numbers.
• Large file systems - A UFS file system can be as large as 1 terabyte (1 Tbyte) and can have regular files up to 2 gigabytes (2 Gbytes). SunOS system software does not provides striping, which is required to make a logical slice large enough for a 1-Tbyte file system. Products such as Online: DiskSuite^(TM) provide this capability.

The following sections describe how a disk is divided into slices and cylinder groups, and structured as a UFS file system.

---

Note - SunOS device names use the term slice (and the letter "s" in the device name) to refer to the slice number.

---

Figure 1-1 shows how a disk slice can be formatted to contain a UFS file system.

Figure 1-1

The following sections describe disk slices, cylinder groups, and cylinder divisions.

Disk Slices

A slice is composed of a single range of contiguous blocks, and is a physical subset of the disk (except for slice 2, which customarily represents the entire disk). Before you can create a file system on a disk, you must format and divide it into slices. See Peripherals Administration for complete information on installing and formatting disks, and dividing disks into slices.

A slice can be used as a raw device for swap space or to hold one and only one UFS file system. A disk can be divided into as many as eight slices. See the Administration Supplement for Solaris Platforms for a list of customary disk slice assignments.

· How to Get Information About Disks and Disk Slices

1. Become superuser.

2. Type format and press Return.

   A list of available disks is displayed.

3. Type a number for the disk you want information about.

   The format menu and the format> prompt are displayed.

---

Caution - Be sure you follow the steps exactly so that you choose the right options from the format and partition menus. You can cause major system damage and data loss if you inadvertently reformat a disk or choose some other potentially destructive option from these menus. See the Administration Supplement for Solaris Platforms manual for information on the format command.

---

4. Type partition and press Return.

   The partition menu and the partition> prompt are displayed.

5. Type print and press Return.

   A list of the slices currently defined for the disk is displayed. Any slices with values of zero are not defined.

6. Type quit and press Return.

   The format menu and the format> prompt are displayed.

7. Type quit and press Return.

   The shell prompt is displayed.

This example shows disk information for /dev/dsk/c0t3d0. Note that the format command does not show slice information as part of the available disk selections. It shows the controller, target, and disk number for each disk.

Code Example 1-1 Using the format Command (1 of 2)

jupiter% su Password: # format AVAILABLE DISK SELECTIONS: 0. c0t0d0 at scsibus0 slave 24 sd0: <SUN0207 cyl 1254 alt 2 hd 9 sec 36> 1. c0t3d0 at scsibus0 slave 0: veryloud sd3: <SUN0207 cyl 1254 alt 2 hd 9 sec 36> Specify disk (enter its number): 1 FORMAT MENU: disk - select a disk type - select (define) a disk type partition - select (define) a partition table current - describe the current disk format - format and analyze the disk repair - repair a defective sector label - write label to the disk analyze - surface analysis defect - defect list management backup - search for backup labels verify - read and display labels save - save new disk/partition definitions inquiry - show vendor, product and revision volname - set 8-character volume name quit format> partition PARTITION MENU: 0 - change '0' partition 1 - change '1' partition 2 - change '2' partition 3 - change '3' partition 4 - change '4' partition 5 - change '5' partition 6 - change '6' partition 7 - change '7' partition select - select a predefined table modify - modify a predefined partition table name - name the current table

Code Example 1-1 Using the format Command (2 of 2)

print - display the current table label - write partition map and label to the disk quit partition> print Volume: veryloud Current partition table (original sd3): Part Tag Flag Cylinders Size Blocks 0 root wm 0 - 39 14.06MB (40/0/0) 1 swap wu 40 - 199 56.25MB (160/0/0) 2 backup wm 0 - 1150 404.65MB (1151/0/0) 3 unassigned wm 0 0 (0/0/0) 4 unassigned wm 0 0 (0/0/0) 5 - wm 0 10.20MB (29/0/0) 6 usr wm 200 - 228 121.29MB (345/0/0) 7 home wm 574 - 1150 202.85MB (577/0/0 partition> quit format> quit #

If you know the disk and slice number, you can display information for a disk using the prtvtoc (print volume table of contents) command. You can specify the volume by specifying any non-zero-size slice defined on the disk (for example, /dev/rdsk/c0t3d0s2 for all of disk 3, or /dev/rdsk/c0t3d0s7 for the eighth slice of disk 3). If you know the target number of the disk, but do not know how it is divided into slices, you can show information for the entire disk by specifying either slice 2 or slice 0.

1. Become superuser.

2. Type prtvtoc /dev/rdsk/cntndnsn and press Return. Information for the disk and slice you specify is displayed.

In this example, information is displayed for all of disk 3:

Code Example 1-2 Using the prtvtoc Command

jupiter% su Password: # prtvtoc /dev/rdsk/c0t3d0s2 * /dev/rdsk/c0t3d0s2 (volume "") partition map

Code Example 1-2 Using the prtvtoc Command (Continued)

* * Dimensions: * 512 bytes/sector * 36 sectors/track * 9 tracks/cylinder * 324 sectors/cylinder * 1272 cylinders * 1254 accessible cylinders * * Flags: * 1: unmountable * 10: read-only * * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 2 5 01 0 406296 406295 6 4 00 0 242352 242351 7 0 00 242352 163944 406295 /files7

Size Restrictions on UFS File Systems

Total Size The limit on the total size of a file system is 1 Tbyte. A UFS file system can be as big as the slice that holds it.

Maximum File Size The maximum size for any one file in a UFS file system is 2 Gbyte.

Maximum Number of Files The maximum number of files per UFS file system is determined by the number of inodes allocated for a file system. The number of inodes depends on how much disk space is allocated for each inode and the total size of the file system. By default, one inode is allocated for each 2 Kbyte of data space. You can change the default allocation using the -i option of the newfs command.

Logical Block and Fragment Size Fragments are small logical blocks that are created to save space by reducing unused portions of logical blocks. The maximum logical block and fragment size is 8192 bytes, although fragments are typically less than or equal to the size of logical blocks.

Cylinder Groups

You create a UFS file system on a disk slice, which is divided into one or more areas called cylinder groups. A cylinder group is composed of one or more consecutive disk cylinders (the set of tracks on a group of platters that have the same radial distance from the center of the platter). See Peripherals Administration for a complete description of disk geometry.

A cylinder group map is created for each cylinder group. The cylinder group map records the block usage and available blocks.

Types of Blocks

Cylinder groups are divided into blocks to control and organize the structure of the files within the cylinder group. Each type of block has a specific function in the file system. A UFS file system has four types of addressable blocks as well as additional information management disk areas. The four types of blocks are:

• Boot block - Used to store information used when booting the system
• Superblock - Used to store much of the information about the file system
• Inode - Used to store all information about a file except its name
• Storage or data block - Used to store data for each file

See Appendix A, "File System Reference," for more detailed information about each type of block.

Planning UFS File Systems

Once disks are formatted and divided into slices, you need to make a file system on each slice that will contain UFS files. See the Peripherals Administration for detailed information on how to format disks and divide them into slices.

When laying out file systems, you need to consider possible conflicting demands. Here are some suggestions:

• Distribute the work load as evenly as possible among different I/O systems and disk drives. Distribute /home and swap directories evenly across disks.
• Keep projects or groups within the same file system.
• Use as few file systems per disk as possible. On the system (or boot) disk you usually have three slices: /, /usr, and a swap area. On other disks create one or at most two slices. Fewer, roomier slices cause less file fragmentation than many small, over-crowded slices. Higher-capacity tape drives and the ability of ufsdump to handle multiple volumes make it easier to back up larger file systems.
• Most sites do not need to be concerned about keeping similar types of user files in the same file system. Infrequently, you may have some users who consistently create very small or very large files. In such a case, you might consider creating a separate file system with more inodes for users who consistently create very small files.

File System Parameters

To make a new file system on a disk slice, you almost always use the newfs command. Table 1-3 shows the default parameters the newfs command uses:

Table 1-3 newfs

Parameter	Default Value
Block size	8 Kbyte
Fragment size	1 Kbyte
Minimum free space	10%
Rotational delay	Device-dependent
Optimization type	Space
Number of inodes	1 for each 2 Kbyte of disk space

If you want to customize a file system using arguments to the newfs command or with the mkfs command, see Appendix A, "File System Reference," for information about altering these parameters.

Making File Systems Available

Once you have created a file system, you need to make it available. You make file systems available by mounting them. A mounted file system is attached to the system directory tree at the specified mount point, and becomes available to the system. The root file system is always mounted. Any other file system can be connected or disconnected from the root file system.

You can mount a local file system in these ways:

• By creating an entry in the /etc/vfstab (virtual file system table) file. The /etc/vfstab file contains a list of file systems that are automatically mounted when the system is booted to multiuser state. See "The Virtual File System Table" on page 26 for a description of the /etc/vfstab file.
• From the command line using the mount command.

File systems on disk slices must always be mounted on the server system and shared (exported) before other systems can access them. See "Sharing Files From a Server" on page 29 and Chapter 3, "Mounting and Unmounting File Systems," for information about sharing file systems. When file systems are shared from a server, a client can mount them as NFS file systems in any of these three ways:

• By adding an entry to the /etc/vfstab (virtual file system table) file so that the file system is automatically mounted when the system is booted to multiuser state.
• By using the autofs to automatically mount or unmount the file system when a user changes into (mount) or out of (umount) the directory. See NFS Administration Guide for information about autofs.
• By using the mount command at a command line.

CD-ROMs containing file systems are mounted when the CD-ROM is inserted. Diskettes containing file systems are mounted by running the volcheck(1) command.

Understanding Mounting and Unmounting

File systems can be attached to the hierarchy of directories available on a system. This process is called mounting. You need to determine whether the file system should be:

• Entered in the /etc/vfstab file to be mounted each time the system is booted
• Whether it can be appropriately mounted using autofs
• Whether it will be used only temporarily, and can be mounted from the command line

To mount a file system you need:

• To be superuser
• A mount point on the local system. The mount point is a directory to which the mounted file system is attached.
• The resource name of the file system to be mounted (for example, /usr)

As a general rule, local disk slices should always be included in the /etc/vfstab file. Any software from servers, such as OpenWindows or manual pages, and home directories from a server can be either included in the /etc/vfstab file or automounted, depending on the policy at your site.

When you mount a file system, any files or directories that might be present in the mount point directory are unavailable as long as the file system is mounted. These files are not permanently affected by the mounting process, and become available again when the file system is unmounted. However, mount directories are usually empty, because you usually do not want to obscure existing files.

Figure 1-2 shows the root file system with subdirectories sbin, etc, and home:

Figure 1-2

To attach a user's home directory to the empty /home directory mount point, first create a directory for the new user. For a user named ignatz, create a directory in /home named ignatz, giving it the appropriate permissions and ownership. Then mount the file system. When the ignatz file system is mounted, all of the files and directories in /home/ignatz are available, as shown in Figure 1-3. You can also create other user directories in the /home directory and use those directories as mount points for other user file systems. See Chapter 3, "Mounting and Unmounting File Systems," for information on how to perform these tasks.

Figure 1-3

---

Note - This example illustrates the concept of mounting. Because /home is, by default, an autofs mount point directory, home directory files would be mounted by autofs rather than the mount command.

---

Whenever you mount or unmount a file system, the /etc/mnttab (mount table) file is modified to show the list of currently mounted file systems. You can display the contents of the mount table using the cat or more commands, but you cannot edit it, as you would the /etc/vfstab file. Here is an example of a mount table file:

mars% more /etc/mnttab /dev/dsk/c0t3d0s0 / ufs rw,suid 693186371 /dev/dsk/c0t1d0s6 /usr ufs rw,suid 693186371 /proc /proc proc rw,suid 693186371 swap /tmp tmpfs ,dev=0 693186373 swsvr4-50:/export/svr4/openwinV3.jpb1 /usr/openwin nfs rw,dev=21c0000 693186443 swsvr4-50:/export/svr4/man /usr/man nfs rw,dev=21c0001 693186447 mars:(pid127) /nse nfs ro,ignore,map=/etc/auto.nse,indirect,dev=21c0002 693186449 mars:(pid127) /net nfs ro,ignore,map=-hosts,indirect,dev=21c0003 693186449 mars:(pid127) /home nfs ro,ignore,map=/etc/auto_home,indirect,dev=21c0004 693186449 neptune:/export/home/neptune /tmp_mnt/home/neptune nfs rw,dev=21c0005 693186673 mars%

Unmounting a file system removes it from the file system mount point, and deletes the entry from the /etc/mnttab file. Some file system administration tasks cannot be performed on mounted file systems. You should unmount a file system when:

• It is no longer needed or has been replaced by a file system that contains more current software.
• You check and repair it using the fsck command. See Chapter 12, "Checking File System Integrity," for more information about the fsck command.

It is a good idea to unmount a file system before doing a complete backup of it. See Chapter 7, "Backing Up Files and File Systems," for more information about doing backups.

---

Note - File systems are automatically unmounted as part of the system shutdown procedure.

---

The Virtual File System Table

The default file system configuration table (the /etc/vfstab file) depends on the selections you make when installing system software. You should edit the /etc/vfstab file for each system to automatically mount local UFS file systems, essential NFS file systems, and any other appropriate file systems.

This section describes the /etc/vfstab file. See Chapter 3, "Mounting and Unmounting File Systems," for information on how to edit and use the file. The file system table is an ASCII file. Comment lines begin with #. This example shows an /etc/vfstab file for a system with two disks and two NFS file systems mounted.

# more /etc/vfstab #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options /dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 / ufs 1 no - /proc - /proc proc - no - /dev/dsk/c0t0d0s1 - - swap - no - swap - /tmp tmpfs - yes - /dev/dsk/c0t0d0s6 /dev/rdsk/c0t0d0s6 /usr ufs 2 no - /dev/dsk/c0t3d0s7 /dev/rdsk/c0t3d0s7 /files7 ufs 2 no - cheers:/export/svr4/man.ja5 - /usr/man nfs - yes hard cheers:/export/svr4/openwinV3.ja4 - /usr/openwin nfs - yes hard #

Note that, for / and /usr, the mount at boot field value is specified as no because these file systems are mounted as part of the boot sequence before the mountall command is run. If the automount field value is specified as yes, the mountall program redundantly (and unnecessarily) tries to mount these already mounted file systems. See Administration Supplement for Solaris Platforms for a description of the booting procedure.

An entry in the virtual file system table has the following seven fields:

special fsckdev mountp fstype fsckpass mount-at-boot mntopts

The fields are separated by tab or space characters.

---

Note - You must have an entry in each field in the /etc/vfstab file. If there is no value for the field, be sure to enter a dash (-).

---

special (device to mount)
  The device to mount can be:

• The block special device for local UFS file systems (for example,

    /dev/dsk/c0t0d0s0)
  · The resource name for remote file systems (for example,
    myserver:/export/home for an NFS file system)
  · The name of the slice on which to swap (for example,
    /dev/dsk/c0t3d0s1)
  · The /proc directory and proc file system type

For more information on remote file systems, see NFS Administration Guide.

fsckdev (device to fsck) The raw (character) special device that corresponds to the file system identified by the special field (for example, /dev/rdsk/c0t0d0s0). This determines the raw interface that is used by fsck. Use a dash (-) when there is no applicable device, such as for a read-only file system or a network-based file system.

mountp (mount point)
  The default mount point directory (for example, /usr for
  /dev/dsk/c0t0d0s6).

fstype (FS type) The type of file system identified by the special field.

fsckpass (fsck pass) The pass number used by fsck to decide whether to check a file system. When the field contains a dash (-), the file system is not checked. When the field contains a value greater than zero, the file system is checked; non-UFS file systems with a zero value for fsck pass are checked. For UFS file systems only, when the field contains a zero, the file system is not checked. When fsck is run on multiple UFS file systems that have fsck pass values greater than one and the preen option (-o p) is used, fsck automatically checks the file systems on different disks in parallel to maximize efficiency. When the field contains a value of 1, the file system is checked sequentially. Otherwise, the value of the pass number does not have any effect.

---

Note - In SunOS system software, the fsck pass field does not explicitly specify the order in which file systems are checked.

---

(mount at boot yes or no for whether the file system should be automatically mounted by mountall when the system is booted. Note that this field has nothing to do with autofs.

mntopts (mount options) A list of comma-separated options (with no spaces) that are used in mounting the file system. Use a dash (-) to show no options. See the mount(1M) manual page for a list of the available options.

Commands Used to Mount and Unmount File Systems

Table 1-4 lists the commands in the /usr/sbin directory that you use to mount and unmount file systems.

Table 1-4

Command	Description
mount(1M)	Mounts file systems and remote resources
mountall(1M)	Mounts all file systems specified in a file system table
umount(1M)	Unmounts file systems and remote resources
umountall(1M)	Unmounts all file systems specified in a file system table

The mount commands will not mount a read/write file system that has inconsistencies. If you receive an error message from the mount or mountall command, you may need to check the file system. See Chapter 12, "Checking File System Integrity," for information on how to check the file system.

The umount commands will not unmount a file system that is busy. A file system is considered busy if a user is in a directory in the file system, or if a program has a file open in that file system. See Chapter 3, "Mounting and Unmounting File Systems," for more information.

The Automounter

You can mount file systems shared through NFS using a method called automounting. autofs runs in the background and mounts and unmounts remote directories as they are needed. Whenever a user on a client system running autofs accesses a remote file or directory available through autofs, it mounts the file system on the user's system. The remote file system remains mounted as long as the user remains in the directory and is using a file. If the remote file system is not accessed for a certain period of time, it is automatically unmounted. autofs mounts and unmounts file systems as required without any intervention on the part of the user other than changing into or out of a directory.

You can mount some file hierarchies with autofs, and others using the /etc/vfstab file and the mount command. A diskless machine must have entries for / (root), /usr, and /usr/kvm in the /etc/vfstab file. Because shared file systems should always remain available, do not use autofs to mount /usr/share.

The autofs works with the file systems specified in maps. These maps can be maintained as NIS, NIS+, or local files.

The autofs maps can specify several remote locations for a particular file. This way, if one of the servers is down, autofs can try to mount from another machine. You can specify which servers are preferred for each resource in the maps by assigning each server a weighting factor.

The autofs starts automatically when a system enters run level 3. You can also start it from a command line. See NFS Administration Guide for complete information on how to set up and administer autofs.

By default, the SunOS system software automounts /home.

Sharing Files From a Server

NFS is a distributed file system that can be used to "tie together" computers that are running different operating systems. For example, systems running DOS can share files with systems running UNIX.

NFS makes the actual physical location of the file system irrelevant to the user. You can use NFS to allow users to see all the relevant files, regardless of location. Instead of placing copies of commonly used files on every system,

NFS allows you to place one copy on one system's disk and let all other systems access it across the network. Under NFS, remote file systems are virtually indistinguishable from local ones.

A system becomes an NFS server if it has file systems to share or export over the network. A server keeps a list of currently exported file systems and their access restrictions (such as read/write or read-only).

You may want to share resources, such as files, directories, or devices from one system on the network (typically, a server) with other systems. For example, you might want to share third-party applications or source files with users on other systems.

When you share a resource, you make it available for mounting by remote systems.

You can share a resource in these ways:

• Using the share or shareall command
• Adding an entry to the /etc/dfs/dfstab (distributed file system table) file

The default /etc/dfs/dfstab file shows you the syntax and an example of entries:

venus% more /etc/dfs/dfstab # place share(1M) commands here for automatic execution # on entering init state 3. # # share [-F fstype] [ -o options] [-d "<text>"] <pathname> [resource] # .e.g, # share -F nfs -o rw=engineering -d "home dirs" /export/home2 share -F nfs /var/mail venus%

Add one entry to the /etc/dfs/dfstab file for each resource that you want to have shared automatically. Each entry must be on a separate line, using this syntax:

share [-F nfs] [-o specific-options] [-d "description"] pathname resource

-F nfs Indicates that the file system type is NFS. If you have only one distributed file system package installed, nfs is the default, and you can omit the -F option.

-o specific-options Is a comma-separated list of options that regulates how the resource is shared. Specific options that can follow the -o flag include:

rw

Shares pathname read/write to all clients (by default), except those that are specified under ro=.

ro

Shares pathname read-only to all clients, except those that are specified under rw=.

---

Note - You cannot specify both rw and ro without arguments, and you cannot specify the same client in the rw= list and the ro= list. If no read/write option is specified, the default is read/write for all clients.

---

ro=client[:client]

Shares pathname read-only to the listed client machines or netgroup names (overriding rw).

rw=client[:client]

Shares pathname read/write to the listed client machines or netgroup names (overriding ro).

anon=uid

Lets you specify a different uid for ''anonymous'' users--users whose uid is 0, the UID of root on Solaris 2.3 systems--when accessing pathname. By default, anonymous users are mapped to username nobody, which has the UID UID_NOBODY. User nobody has ordinary user privileges, not superuser privileges.

root=host[:host]

Lets a user from host host, whose uid is 0, access pathname as root; root users from all other hosts become anon. If this option is not specified, no user from any host is granted access to pathname as root.

---

Caution - Granting root access to other hosts has far-reaching security implications; use the root= option with extreme caution.

---

secure

Shares a resource with additional user authentication required (see Security, Performance, and Accounting Administration for more information).

kerberos

Shares a resource with Kerberos authentication.

-d description Is a comment that describes the resource to be shared. If you use the -d option, the description is stored in the sharetab file. However, clients do not see the description displayed when they use the dfshares command to list the resources shared on that system.

pathname

Is the full name of the resource to be shared, starting at root (/).

See Chapter 3, "Mounting and Unmounting File Systems," for information on how to share files and NFS Administration Guide for a complete description of NFS.

---

Note - Arguments that accept a client or host list (ro=, rw=, and root=) are guaranteed to work over UDP, but may not work over other transport providers.

---

Under NFS, a server shares resources it owns so clients can mount them. However, a user who becomes the superuser at a client is denied access as the superuser to mounted remote resources. When a user logged in as root on one host requests access to a remote file shared through NFS, the user's ID is changed from 0 to the user ID of the user name nobody. The access rights of user nobody are the same as those given to the public for a particular file. For example, if the public has only execute permission for a file, then user nobody can execute only that file.

See Chapter 3, "Mounting and Unmounting File Systems," for information on how to share files and file systems.