Chapter 26 File Systems (Overview)

This is a list of the overview information in this chapter.

• "Types of File Systems"

• "File System Administration Commands "

• "The Default Solaris File Systems "

• "Swap Space"

• "The UFS File System"

• "Size Restrictions on UFS File Systems"

• "Mounting and Unmounting"

• "Determining a File System's Type"

A file system is a structure of directories used to organize and store files. The term "file system" is used in several different ways:

• To describe a particular type of file system: disk-based, network-based, or virtual

• To describe the entire file tree from the root directory downward

• To describe the data structure of a disk slice or other media storage device

• To describe a portion of a file tree structure that is attached to a mount point on the main file tree so that it is accessible

Usually, you can tell from context which meaning is intended.

The Solaris system software uses the virtual file system (VFS) architecture, which provides a standard interface for different file system types. The VFS architecture enables the kernel to handle basic operations, such as reading, writing, and listing files, without requiring the user or program to know about the underlying file system type.

The file system administrative commands provide a common interface that enables you to maintain file systems of differing types. These commands have two components: a generic component and a component specific to each type of file system. The generic commands apply to most types of file systems, while the specific commands apply to only one type of file system.

Administering file systems is one of your most important system administration tasks. Read this chapter for file system background and planning information. Refer to other chapters in this part or to other parts in the System Administration Guide for instructions about these tasks:

• Setting up new UFS and virtual file systems - See Chapter 27, Creating File Systems (Tasks) and Chapter 29, The Cache File System (Tasks) for detailed information. The various types of virtual file systems are described later in this chapter.

• Making local and remote files available to users - See Chapter 28, Mounting and Unmounting File Systems (Tasks) for detailed information.

• Connecting and configuring new storage devices - See Chapter 21, Disk Management (Overview) for detailed information.

• Designing and implementing a backup schedule and restoring files and file systems as needed - See Chapter 33, Backing Up and Restoring File Systems (Overview) for information about backing up and restoring files and file systems.

• Checking for and correcting file system damage - See Chapter 31, Checking File System Integrity for detailed information on how to proceed if the automatic (boot time) checking fails.

What's New in File Systems?

The Solaris 2.6 release provides a few new file system features. Each of these new features is described in the following sections.

Large Files

A new option to the mount command, -largefiles, is the default mount option for the Solaris 2.6 environment. This option allows you to create file systems containing files larger than 2GB. The -largefiles option means that a filesystem mounted with this option may contain files larger than 2GB, but it is not a requirement. See Chapter 28, Mounting and Unmounting File Systems (Tasks) for more information on mounting file systems containing large files.

NFS Client Failover

The NFS client failover feature lets you specify additional hosts from which to mount a file system in case the first host selected cannot be reached. You can either set this up in the /etc/vfstab file, or issue your list of hosts from the command line.

WebNFS

The WebNFS^TM feature (sometimes called "Public NFS") provides two additional options to the mount command for the Solaris 2.6 release:

-index filename causes a file matching filename to be automatically loaded if it is found in a directory referenced by an NFS URL.

-public resets the public file handle to the current directory. This enables you to have access through an NFS URL even if the file system cannot be mounted by normal means.

Types of File Systems

The Solaris system software supports three types of file systems:

• Disk-based

• Network-based

• Virtual

To identify the type for a particular file system, see "Determining a File System's Type".

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 file system (based on the BSD Fast File system that was provided in the 4.3 Tahoe release). UFS is the default disk-based file system in Solaris 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. Solaris 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

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 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 distributed file system for Solaris. You administer distributed file systems by exporting them from a server and mounting them on individual systems. See "Mounting and Unmounting" for more information.

Virtual File Systems

Virtual file systems are memory-based file systems that provide access to special kernel information and facilities. Most virtual file systems do not use file system disk space. However, Cache File Systems use a file system on the disk to contain the cache, and some virtual file systems, such as the Temporary File System, use the swap space on a disk.

The Cache File System

The Cache File System (CacheFS^TM) can be used to improve performance of remote file systems or slow devices such as CD-ROM drives. 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 29, The Cache File System (Tasks) for detailed information on setting up and administering Cache File Systems.

The Temporary File System

The Temporary File System (TMPFS) 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 Solaris system software. You can copy or move files into or out of the /tmp directory, just as you would in a UFS 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 27, Creating File Systems (Tasks) for information on how to create TMPFS file systems. See Chapter 30, Configuring Additional Swap Space (Tasks) for information about increasing swap space.

The Loopback File System

The Loopback File System (LOFS) lets you create a new virtual file system so you can access files by using an alternative path name. For example, you can create a loopback mount of root / 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 27, Creating File Systems (Tasks) for information on how to create LOFS file systems.

The Process File System

The Process File System (PROCFS) 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 by using file system calls. The following example shows a partial listing of the contents of the /proc directory:

$ 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

Do not delete the files in the /proc directory. Deleting processes from the /proc directory is not the best 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 Virtual File Systems

These additional types of virtual 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 26-1 lists the generic file system administrative commands, which are located in the /usr/sbin directory.

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

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] 

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 the -F option, 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.

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).

The Default Solaris File Systems

The Solaris 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 26-3 provides a summary of the default Solaris file systems, and shows the type of each file system. See Chapter 32, File System Reference for more detailed information on the default directories for the root and /usr file systems.

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 Chapter 32, File System Reference for a complete list of the default directories.

Swap Space

The Solaris system software uses some disk slices for temporary storage rather than for file systems. These slices are called swap slices. Swap slices are used as virtual memory storage areas when the system does not have enough physical memory to handle current processes.

The Solaris 2.x virtual memory system maps physical copies of files on disk to virtual addresses in memory. Physical memory pages which hold the data for these mappings can be backed by regular files in the file system or by swap space. If the memory is backed by swap space it is referred to as anonymous memory because the user doesn't know the names of the files backing the memory.

For a complete conceptual overview of swap space, instructions for adding more swap space, and information on the differences between Solaris 1.x (SunOS 4.x) and Solaris 2.x (SunOS 5.x) swap requirements, see Chapter 30, Configuring Additional Swap Space (Tasks).

The UFS File System

UFS is the default disk-based file system in Solaris system software. Most of the time, when you administer a disk-based file system, you will be administering UFS. UFS 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," file system checks are 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 Tbyte (terabyte) and can have regular files up to 2 Gbytes (gigabytes). The Solaris system software does not provide striping, which is required to make a logical slice large enough for a 1-Tbyte file system. However, the Solstice DiskSuite(TM) software, available from SunSoft, provides this capability.

Solaris device names use the term slice (and the letter "s" in the device name) to refer to the slice number. Slices used to be called "partitions" in SunOS 4.x.

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

Figure 26-1 How a Disk Slice Is Formatted for a UFS File System

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

Disk Slices

A slice is composed of a single range of contiguous blocks. It 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 it and divide it into slices. See Part VII 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 UFS file system. A disk can be divided into as many as eight slices. See Part VII for a list of customary disk slice assignments.

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.

Example 26-1 Using the format Command

$ 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
 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.

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 Chapter 21, Disk Management (Overview) 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 and 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 Chapter 32, File System Reference for more detailed information about each type of block.

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

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 depends on the way the file system is configured.

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.

Planning UFS File Systems

After disks are formatted and divided into slices, you need to make a file system on each slice that will contain UFS files. See Chapter 22, Administering Disks (Tasks) 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 /export/home and swap directories evenly across disks.

• Keep pieces of projects or members of 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.

• If you have some users who consistently create very small files, consider creating a separate file system with more inodes. However, most sites do not need to be concerned about keeping similar types of user files in the same file system.

See Chapter 27, Creating File Systems (Tasks) for information on default file system parameters as well as prerequisites and procedures for creating new file systems.

Mounting and Unmounting

File systems can be attached to the hierarchy of directories available on a system. This process is called mounting. A mounted file system is attached to the system directory tree at the specified mount point (a directory to which the mounted file system is attached), 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 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 the file system can be appropriately mounted using AutoFS

• Whether the file system will be used only temporarily

• Whether the file system 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 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 software or man pages, and home directories from a server can be either included in the /etc/vfstab file or automatically mounted with the automount command, depending on the policy at your site.

When you mount a file system, any files or directories 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 26-2 shows the root (/) file system with subdirectories sbin, etc, and home:

Figure 26-2 A File System

To attach a user's home directory to the empty /export/home directory mount point, first create a directory for the new user. For a user named ignatz, create a directory in /export/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 /export/home/ignatz are available, as shown in Figure 26-3. You can also create other user directories in the /export/home directory and use those directories as mount points for other user file systems. See Chapter 28, Mounting and Unmounting File Systems (Tasks)for information on how to perform these tasks.

Figure 26-3 Mounting a Home Directory File System

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 with 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:

$ more /etc/mnttab
/dev/dsk/c0t3d0s0    /       ufs     rw,suid,dev=800018,largefiles 863804345
/dev/dsk/c0t3d0s6    /usr    ufs     rw,suid,dev=80001e,largefiles 863804345
/proc   /proc   proc    rw,suid,dev=2900000     863804345
fd      /dev/fd fd      rw,suid,dev=29c0000     863804345
/dev/dsk/c0t3d0s3   /export ufs     suid,rw,largefiles,dev=80001b  863804347
/dev/dsk/c0t3d0s7   /export/home ufs suid,rw,largefiles,dev=80001f 863804348
/dev/dsk/c0t3d0s4   /export/swap ufs suid,rw,largefiles,dev=80001c 863804348
/dev/dsk/c0t3d0s5   /opt  ufs   suid,rw,largefiles,dev=80001d  863804347
swap    /tmp    tmpfs   dev=2a80000     863804347
$

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 31, 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 33, Backing Up and Restoring File Systems (Overview) for more information about doing backups.

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.

The following is an example of the /etc/vfstab 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 root (/) 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 Chapter 5, Shutting Down and Booting a System (Overview) for a description of the booting procedure.

See Chapter 28, Mounting and Unmounting File Systems (Tasks) for descriptions of each of the /etc/vfstab fields and information on how to edit and use the file.

Automounting Directories

You can mount file systems shared through NFS by using a method called automounting. Running in the background, the AutoFS program 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.

AutoFS works with the file systems specified in maps. These maps can be maintained as NIS, NIS+, or local /etc 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.

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

By default, the Solaris 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:

• By using the share or shareall command

• By 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:

$ more /etc/dfs/dfstab
#   Place share(1M) commands here for automatic execution
#   on entering init state 3.
#
#   Issue the command '/etc/init.d/nfs.server start' to run the NFS
#   daemon processes and the share commands, after adding the
#   very first entry to this file.
#
#   share [-F fstype] [ -o options] [-d ""]  [resource]
#   .e.g,
#   share  -F nfs  -o rw=engineering  -d "home dirs"  /export/home2
share -F nfs /var/mail
$

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

Table 26-4 describes these variables.

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.

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

See Chapter 28, Mounting and Unmounting File Systems (Tasks) for information on how to share files and file systems. See the NFS Administration Guide for a complete description of NFS.

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 root as a client is denied access as root 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.

Determining a File System's Type

You can determine a file system's type by using the following:

• 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

How to Determine the Type of a File System

Use the grep command to find a file system's type in the /etc/vfstab file:

$ grep /tmp /etc/vfstab
swap       -          /tmp     tmpfs   -     yes    -
$

Information for the mount point is displayed.

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

How to Determine a Mounted File System's Type

Search the /etc/mnttab for the mount-point directory.

$ 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  nfsrw,
dev=21c0005 695409833

Information about the mount point is displayed.

Or

1. Use the devnm command to display the raw device name of the mounted file system.

   $ devnm /filesystem

   /filesystem

   Is the mounted file system whose raw device name you want to identify.

2. Become superuser.

3. Use the fstyp command to display the file system type.

   # fstyp dev/rdsk/device-name

   /dev/rdsk/device-name

   Is the name of the raw device containing the file system you want to identify.

Example--Determining a Mounted File System's Type

The following example uses the devnm command to identify the name of the device that contains /usr, a mounted file system. Next, the fstyp command is used to identify what type of file system /usr is.

$ devnm /usr
/dev/dsk/cot3d0s6 /usr
$ su
# fstyp /dev/rdsk/c0t3d0s6
ufs

How to Find Out Which File Systems are Mounted on What Disk Slices

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. Display disk and slice information.

   # prtvtoc /dev/rdsk/devicename

   /dev/rdsk/device-name

   Is the name of the raw device containing the file system you want to identify.

Example--Finding Out Which File Systems are Mounted on What Disk Slices

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

$ su
Password:
# prtvtoc /dev/rdsk/c0t3d0s2
* /dev/rdsk/c0t3d0s2 (volume "") partition map
*
* 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