4    File Systems

This chapter describes the various file systems provided by the Tru64 UNIX operating system. Following a brief overview (Section 4.1), the following file systems are discussed:

• Virtual File System (Section 4.2)

• Advanced File System (Section 4.3)

• UNIX File System (Section 4.4)

• Network File System (Section 4.5)

• Compact Disk Read-Only Memory File System (Section 4.6)

• Memory File System (Section 4.7)

• The /proc File System (Section 4.8)

• File-on-File Mounting File System (Section 4.9)

• File Descriptor File System (Section 4.10)

4.1    Overview

The file systems provided by Tru64 UNIX are all accessed through a Virtual File System (VFS) layer, and are integrated with the virtual memory Unified Buffer Cache (UBC).

The file system that you see is handled by the Virtual File System layer, which interacts with the local file system or the networked file system. Under Tru64 UNIX, the default file system is the Advanced File System (AdvFS), although the traditional UNIX File System (UFS) is also available. From there, the networked file system or the local file system might interface with the Logical Storage Manager, and in turn, the device drivers and the physical storage devices. Figure 4-1 illustrates this interplay of the file systems, the Logical Storage Manager (LSM), and the physical storage devices.

Figure 4-1:  File Systems

4.2    Virtual File System

The Virtual File System (VFS) is based on the Berkeley 4.3 Reno virtual file system. VFS presents a uniform interface to users and applications, an interface that is abstracted from the file system layer to allow common access to files, regardless of the file system on which they reside. As a result, file access across different file systems is transparent to the user.

A structure known as a vnode contains information about each file in a mounted file system. The vnodes are analogous to inodes: they are more or less wrappers around file system-specific nodes. If, for example, a read or write request is made on a file, the vnode points the system call to the routine appropriate for that file system. A read request is pointed to advfs_read when the request is made on a file in AdvFS; to ufs_read when the request is made on a file in a UFS; or to nfs_read when the request is made on a file in an NFS-mounted file system.

The Tru64 UNIX VFS implementation supports Extended File Attributes (XFAs), including support for any application that wants to assign an XFA to a file. Both AdvFS and UFS support XFAs. For more information on XFAs, see the setproplist(2) reference page.

4.3    Advanced File System

The Advanced File System (AdvFS) is the default root file system for Tru64 UNIX; it is a log-based file system that provides flexibility, compatibility, data availability, high performance, and simplified system management. AdvFS handles files and filesets approaching 16 terabytes in length.

The configuration of AdvFS differs from the traditional UNIX file system. In AdvFS, the physical storage layer is managed independently of the directory layer. System administrators can add and remove storage without unmounting the file system or halting the operating system. As a result, configuration planning is less complicated and more flexible.

From a user's perspective, AdvFS behaves like any other UNIX file system. You can use the mkdir command to create new directories, the cd command to change directories, and the ls command to list directory contents. AdvFS logical structures, quota controls, and backup capabilities are based on traditional file system design. AdvFS has its own complement of file system maintenance utilities, including mkfdmn and mkfset, which create file systems, and vdump and vrestore, which back up and restore filesets. AdvFS commands and utilities are described in the AdvFS Administration guide.

Without taking an AdvFS off line, system administrators can perform backups, file system reconfiguration, and file system tuning. End users can retrieve their own unintentionally deleted files from predefined trashcan directories or from clone filesets without assistance from system administrators.

AdvFS supports multivolume file systems, which enables file-level striping (spreading data to more than one volume) to improve file transfer rates for I/O intensive applications. Logical Storage Manager (LSM), which allows volume-level striping, can be incorporated into AdvFS configurations.

The separately licensed AdvFS Utilities (Table 4-1) provide additional file management capabilities and a Web-based graphical user interface to simplify system administration. The graphical interface, which runs under the Common Desktop Environment (CDE), features menus, graphical displays, and comprehensive online help that make it easy to perform AdvFS operations. In addition, the graphical interface displays summarized system status information.

Table 4-1:  AdvFS Features and Benefits

The following features were added to AdvFS in Version 5.0:

• Improved disk structure that increases the number of files the file domain can track

• A disk salvage utility that can recover information at the block level from disks that have been damaged

• An improved directory structure that increases the speed of file creation and access

• Enhanced vdump and vrestore command capability

• Remote device support for backup and restore

• Increased quota limits

• Direct I/O to allow unbuffered, synchronous I/O

• Smooth sync option to promote continuous I/O

• New utilities (such as vdf, which displays disk usage for file domains and filesets)

• Metadata display utilities

4.4    UNIX File System

The UNIX File System (UFS) is a local file system. At one time, UFS was the principal file system, and it is still a vital alternative to the use of AdvFS.

UFS is compatible with the Berkeley 4.3 Tahoe release. UFS allows a pathname component to be 255 bytes, with the fully qualified pathname length restriction of 1023 bytes. The Tru64 UNIX implementation of UFS supports file sizes that exceed 2 GB.

UFS supports file block clustering, thereby producing sequential read and write access that is equivalent to the raw device speed of the mass storage device. UFS supports file-on-file mount for STREAMS (see Section 4.9).

4.5    Network File System

The Network File System (NFS) is a facility for sharing files in a heterogeneous environment of processors, operating systems, and networks. NFS does so by mounting a remote file system or directory on a local system and then reading or writing the files as though they were local.

The Tru64 UNIX environment supports NFS Version 3 and NFS Version 2. The NFS Version 2 code is based on ONC Version 4.2, which is licensed from Sun Microsystems; the NFS Version 3 code is derived from prototype code from Sun Microsystems.

Because Tru64 UNIX supports both NFS Version 3 and Version 2, the NFS client and server bind at mount time using the highest NFS version number they both support. For example, a Tru64 UNIX client will use NFS Version 3 when it is served by an NFS server that supports NFS Version 3; however, when it is served by an NFS server running only NFS Version 2, the NFS client will use NFS Version 2. For more detailed information on NFS Version 3, see the paper NFS Version 3: Design and Implementation (USENIX 1994).

In addition to the basic NFS services, Tru64 UNIX supports these enhancements:

• NFS over TCP

• Write-gathering

• NFS-locking

• Automounting

• PC-NFS

• WebNFS

4.5.1    NFS Version 3 Features

NFS Version 3 supports all the features of NFS Version 2 and the following:

• Improved performance

  • Support for reliable asynchronous writes, which improves write performance over NFS Version 2 by a factor of seven, thereby reducing client response latency and server I/O loading

  • Support for a READDIRPLUS procedure that returns file handles and attributes with directory names to eliminate LOOKUP calls when scanning a directory

  • Support for servers to return metadata on all operations to reduce the number of subsequent GETATTR procedure calls

  • Support for weak cache consistency data to allow a client to manage its caches more effectively

• Improved security

  • Provides an ACCESS procedure that fixes the problems in NFS Version 2 with superuser permission mapping, and allows access checks at file-open time, so that the server can better support Access Control Lists (ACLs)

  • File names and pathnames specified as strings of variable length, with the maximum length negotiated between the client and server using the PATHCONF procedure

• Guaranteed exclusive creation of files

4.5.2    Enhancements to NFS

In addition to the NFS Version 3.0 functions, Tru64 UNIX features the following enhancements to NFS:

• NFS over TCP

  Although NFS has been traditionally run over the UDP protocol, Tru64 UNIX supports NFS over the TCP protocol. For more information, see the mount(8) reference page.

• Write-gathering

  On an NFS server, multiple synchronous write requests to the same file are combined to reduce the number of actual writes as much as possible. The data portions of successive writes are cached and a single metadata update is done that applies to all the writes. Replies are not sent to the client until all data and associated metadata are written to disk to ensure that write-gathering does not violate the NFS crash recovery design.

  As a result, write-gathering increases write throughput by up to 100 percent and the CPU overhead associated with writes is substantially reduced, further increasing server capacity.

• NFS-locking

  Using the fcntl system call to control access to file regions, NFS-locking allows you to place locks on file records over NFS protecting segments of a shared, NFS-served database. The status daemon, rpc.statd, monitors the NFS servers and maintains the NFS lock if the server goes down. When the NFS server comes back up, a reclaiming process allows the lock to be reattached.

• Automounting

  The automount daemon automatically and transparently mounts and unmounts NFS file systems on an as-needed basis. It provides an alternative to using the /etc/fstab file for NFS mounting file systems on client machines.

  The automount daemon can be started from the /etc/rc.config file or from the command line. Once started, it sleeps until a user attempts to access a directory that is associated with an automount map or any directory or file in the directory structure. Once awakened, the daemon consults the appropriate map and mounts the NFS file system. After a specified period of inactivity on a file system, five minutes by default, the automount daemon unmounts that file system.

  The maps indicate where to find the file system to be mounted and the mount options to use. An individual automount map is either local or served by NIS. A system, however, can use both local and NIS automount maps.

  Automounting NFS-mounted file systems provides the following advantages over static mounts:

  • If NIS maps are used and file systems are moved to other servers, users do not need to do anything to access the moved files. Every time the file systems need to be mounted, the daemon will mount them from the correct locations.

  • In the case of read-only files, if more than one NFS-server is serving a given file system, automount will connect you to the fastest server that responds. If at least one of the servers is available, the mount will not hang.

  • By unmounting NFS-mounted file systems that have not been accessed for more than a certain interval (five minutes by default), the automount daemon conserves system resources, particularly memory.

• PC-NFS

  Compaq supports the PC-NFS server daemon, pcnfsd, which allows PC clients with PC-NFS configured to do the following:

  • Mount NFS file systems

    The PC-NFS pcnfsd daemon, in compliance with Versions 1.0 and 2.0 of the pcnfsd protocol, assigns UIDs and GIDs to PC clients so that they can talk to NFS.

    The pcnfsd daemon performs UNIX login-like password and user name verification on the server for the PC client. If the authentication succeeds, the pcnfsd daemon then grants the PC client the same permissions accorded to that user name. The PC client can mount NFS file systems by talking to the mountd daemon as long as the NFS file systems are exported to the PC client in the /etc/exports file on the server.

    Because there is no mechanism in Windows to perform file permission checking, the PC client calls the authentication server to check the user's credentials against the file's attributes. This happens when the PC client makes NFS requests to the server for file access that requires permission checking, such as opening a file.

  • Access network printers

    The pcnfsd daemon authenticates the PC client and then spools and prints the file on behalf of the client.

• WebNFS

  WebNFS is an NFS protocol that allows clients to access files over the Internet in the same way that local files are accessed. WebNFS uses a public file handle that allows it to work across a firewall. This public file handle also reduces the amount of time required to initialize a connection. The public file handle is associated with a single directory (public) on the WebNFS server. For more information, see the exports(4), exportfs(2), and nfs_intro(4) reference pages.

4.6    Compact Disk Read-Only Memory File System

The Compact Disk Read-Only Memory File System (CDFS) is a local file system. Tru64 UNIX supports the ISO-9660 CDFS standard for data interchange between multiple vendors; the High Sierra Group standard for backward compatibility with earlier CD-ROM formats; and an implementation of the Rock Ridge Interchange Protocol (RRIP), Version 1.0, Revision 1.09.

The RRIP extends ISO-9660 system use areas to include multiple sessions, mixed-case and long file names; symbolic links; device nodes; deep directory structures; user IDs and group IDs and permissions on files; and POSIX timestamps.

All the code for CDFS has been taken from the public domain and enhanced for Tru64 UNIX.

Additionally, Tru64 UNIX supports the X/Open Preliminary Specification (1991) CD-ROM Support Component (XCDR). XCDR allows users to examine selected ISO-9660 attributes through defined utilities and shared libraries. XCDR also allows system administrators to substitute different file protections, owners, and file names for the default CD-ROM files. For more information, see the cdfs(4) reference page .

4.7    Memory File System

Tru64 UNIX supports a Memory File System (MFS), which is essentially a UNIX File System that resides in memory. No permanent file structures or data are written to disk, so the contents of an MFS are lost on system reboots, unmountings, or power failures. Because it does not write data to disk, the MFS is a very fast file system -- quite useful for storing temporary files or read-only files that are loaded into it after it is created.

For example, if you are building software that would have to be restarted if it failed, MFS is a good choice to use for storing the temporary files that are created during the build process, because the speed of MFS would reduce the build time. For more information about MFS, see the newfs(8) reference page.

4.8    The /proc File System

The /proc file system is a local file system that enables running processes to be accessed and manipulated as files by the system calls open, close, read, write, lseek, and ioctl.

The /proc file system is layered beneath the VFS; it is a pseudo file system that occupies no actual disk space. You can use the mount and unmount commands to manually mount and unmount the file system, or you can define an entry for it in the /etc/fstab file.

While the /proc file system is most useful for debuggers, it enables any process with the correct permissions to control another running process. Thus, a parent/child relationship does not have to exist between a debugger and the process being debugged. For more information, see the proc(4) reference page.

4.9    File-on-File Mounting File System

The File-on-File Mounting (FFM) file system allows regular, character, or block-special files to be mounted over regular files. FFM is used, for the most part, by the Tru64 UNIX system calls fattach and fdetach of a STREAMS-based pipe (or FIFO). The two system calls are SVR4-compatible. By using FFM, a FIFO, which normally has no file system object associated with it, is given a name in the file system space. As a result, a process that is unrelated to the process that created the FIFO can then access the FIFO.

In addition to programs using FFM through the fattach system call, users can mount one regular file on top of another by using the mount command. Mounting a file on top of another file does not destroy the contents of the covered file; it simply associates the name of the covered file with the mounted file, thereby making the contents of the covered file temporarily unavailable. The covered file can be accessed only after the file mounted on top of it is unmounted. Note that the contents of the covered file are still available to any process that had the file open at the time of the call to fattach or had the file open when a user issued a mount command that covered the file. For more information on FFM, see the ffm(4) reference page.

4.10    File Descriptor File System

The File Descriptor File System (FDFS) allows applications to reference a process' open file descriptors as if they were files in UFS. The association is accomplished by aliasing a process's open file descriptors to file objects. When FDFS is mounted, opening or creating a file descriptor file has the same effect as using the dup system call.

FDFS allows applications that were not written with support for UNIX style I/O to use pipes, named pipes, and I/O redirection. FDFS is not configured into the Tru64 UNIX system; it must be mounted by command or must be placed as an entry in the system's /etc/fstab file. For more information on FDFS, see the fd(4) reference page.