The basic design of traditional UNIX file systems has changed little over the years. Traditional file systems require you to take the system down for backup and other maintenance procedures, reconfigure the entire file system just to add space, and run the fsck utility for hours after a system crash. These inflexible file systems cost time and money, and drain limited system-management resources.

Systems that rely on a local file system on a server need flexible, highly available file systems. The POLYCENTER Advanced File System (AdvFS) and the optional AdvFS Utilities offer a UNIX file system that provides fast reboots, support for multivolume file systems, and many online maintenance, performance, and reconfiguration options. These features let you quickly respond to the changing requirements of a dynamic computing environment.

This chapter includes the following sections:

• Flexibility
• Compatibility
• Data Availability
• High Performance
• Simplified File-System Management

File-System Design

• Filesets and File Domains
• Transaction Log
• Extent-Based Allocation
• File-Storage Allocation
• Limitations
• Fragments
• License Registration

AdvFS is a log-based file system with an innovative design that provides flexibility, compatibility, data availability, high performance, and simplified system management. AdvFS takes advantage of the 64-bit computing environment and breaks through the constraints of 2-gigabyte file and file-system limits. It is designed to handle files and filesets as large as almost 16 terabytes.

The AdvFS design overcomes problems associated with system capacity and configuration, such as adding or removing disks. 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. System administrators can perform file-system backups and maintenance without interrupting users, applications, or data availability.

AdvFS logical structures, quota controls, and backup capabilities are based on existing file-system design. This consistency promotes a smooth transition to the new file system.

From a user's perspective, AdvFS behaves like any other UNIX file system. End users can use the mkdir command to create new directories, the cd command to change directories, and the ls command to list directory contents. Application programmers encounter a familiar UNIX-based programming interface: open(), close(), creat(), and so on. AdvFS is POSIX 1003.1 compliant.

AdvFS replaces or eliminates several standard commands, such as newfs, dump, restore, and fsck. All AdvFS commands and utilities are described in Appendix A.

With AdvFS, rebooting after a system interruption is extremely fast. AdvFS uses write-ahead logging, instead of the fsck utility, as a way to check for and repair file-system inconsistencies that can occur when there is a system crash or power failure. The number of uncommitted records in the log, not the amount of data in the file system, dictates the speed of a recovery. As a result, reboots are quick and predictable, taking seconds rather than minutes. User file data can be logged as well, providing better control of data recovery.

To maintain data availability, system administrators can perform backups, file-system reconfiguration, and file-system tuning without taking the system off line.

End users can retrieve their own unintentionally deleted files from predefined trashcan directories or from clone filesets without assistance from system administrators.

An extent-based file allocation scheme allows for fewer and larger I/O transfers, increasing sequential read/write throughput and simplifying large data transfers. The file system performs large reads from disk when sequential access is anticipated. It also performs large writes by combining adjacent data into a single disk transfer.

AdvFS supports multivolume file systems, which enables file-level striping. File-level striping improves file transfer rates by spreading I/O among several disks.

The AdvFS Utilities product provides a graphical user interface (GUI) to simplify system administration. The AdvFS GUI features menus, graphical displays, and comprehensive online help that make it easy to learn and perform AdvFS operations. In addition, the GUI provides summarized system status information, alerts that bring potential trouble to your attention, and scheduling capabilities.

AdvFS introduces features that are unavailable in traditional file systems such as the BSD^TM or the System V file systems. Table 1 lists the main AdvFS features and their benefits:

Table 1 AdvFS Features and Benefits

*This feature requires the optional AdvFS Utilities license.

Before setting up AdvFS, you need to understand how it differs from traditional UNIX file systems. These differences, although minor with regard to your transition from another file system, play a role in how you plan and maintain this file system.

The UNIX File System (UFS) is a good example of a traditional file system. Typical of the UFS model, each disk (or disk partition) contains one separate file system; you mount the file system into the logical name space using mount points.

The UFS model is rigid. The directory hierarchy layer of the file system is bound tightly to the physical storage layer. When a file system becomes full, this tight binding makes it impossible to move selected files onto another disk without changing the full path names of those files.

The task of dividing a logical directory into directory subtrees and mapping the subtrees onto separate disks requires careful consideration. Even with extensive planning, adjustments to the directory structure are limited with the UFS model.

Unlike UFS, AdvFS consists of two distinct layers, namely the directory hierarchy layer and the physical storage layer. The directory hierarchy layer implements the file-naming scheme and Digital UNIX file-system compliant functions such as creating and opening files, or reading and writing to files. The physical storage layer implements write-ahead logging, caching, file allocation, and physical disk I/O functions.

This decoupled file-system structure enables you to manage the physical storage layer apart from the directory hierarchy layer. This means that you can move files between a defined group of disk volumes without changing file path names. Because the path names remain the same, the action is completely transparent to end users.

The two-layer structure is the cornerstone of AdvFS and its design. Supporting the design are two file-system concepts: the fileset and the file domain.

A fileset follows the logical structure of a traditional UNIX file system. It is a hierarchy of directory names and file names, and it is what you mount. AdvFS goes beyond UFS, by allowing you to create multiple filesets that share a common pool of storage within a defined set called a file domain.

A file domain is a pool of storage to which you can add and remove volumes as storage requirements change. A volume in AdvFS can be a single disk partition, an entire disk, or an aggregate volume provided by a logical volume manager.

Figure 1 AdvFS File System Design

AdvFS is a log-based file system that employs write-ahead logging to ensure the integrity of the file system. Write-ahead logging means that modifications to the metadata (file structure information) are completely written to a transaction log before the actual changes are written to disk. The log is implemented as a circular file buffer so that the contents of the transaction log are written to disk at regular intervals. By committing only completed transactions to disk, the file system is not left in an inconsistent state after an unexpected system crash. By default, only file structures are logged for performance reasons. You can choose to log file data.

AdvFS creates a transaction log for each file domain when the domain is created. The first time the file domain is activated, 4 MB of storage are allocated for the log. It is separate from the user data but can be stored on the same device.

During crash recovery, AdvFS consults the transaction log to confirm file-system transactions. All completed transactions are committed to disk and uncompleted transactions are undone. The number of uncommitted records in the log, not the amount of data in the file system, dictates the speed of recovery. This means that recovery usually takes only a few seconds. Traditional UNIX file systems rely on the fsck utility to recover from a system failure. The fsck utility can take hours to check and repair a large file system.

AdvFS always attempts to write each file to disk as a set of contiguous units called pages; a page is 8 kB of disk space. Contiguous in this context means storage that is physically adjacent on a disk volume. A set of one or more contiguous pages is called an extent. When storage is added to a file in AdvFS, it is grouped in extents as opposed to being allocated a block at a time, as in UFS file systems.

Contiguous placement of the pages means that the I/O mechanism works more efficiently. When a file consists of many small extents, the I/O mechanism must work harder to read or write that file.

Files are not static; their space requirements change over time. To maintain contiguous file placement without overallocating space on the disk, AdvFS uses a unique file storage allocation scheme. Each time a file is appended, AdvFS adds pages to the file by preallocating one-fourth of the file size, up to 16 pages. If a large write requires more file space, AdvFS attempts to allocate up to 256 contiguous pages. Excess preallocated space is truncated when the file is closed.

For multivolume file domains, new files are allocated sequentially across volumes. Volumes that are more than 86% full (allocated) are not used for new file allocation unless all volumes are more than 86% full. When existing files are appended, storage is allocated on the volume on which the file was initially allocated, until the volume is full.

When a new volume is added to a file domain, it is added to the storage allocation sequence together with the other volumes. Files are allocated to the new volume in turn.

Given the dynamic nature of a file system, the file-storage allocation cannot always guarantee contiguous page placement. The following factors affect placement:

• Excessive disk fragmentation
  When a disk is fragmented, AdvFS writes data to isolated physical pages, based on availability, instead of writing to contiguous pages.
• Multiple users
  When there are many users on a system, file activity increases, which makes files more fragmented on the disk. File fragmentation can reduce the I/O performance of AdvFS. To reduce fragmentation, use the defragment utility that is available with the optional AdvFS Utilities product.

AdvFS writes files to disk in sets of 8-kB pages. When a file uses only part of the last page (less than 8 kB) a file fragment is created. The fragment, which is from 1 kB to 7 kB in size, is allocated from the frag file. The frag file is a special file used for storing the file fragments. It is not visible in the directory hierarchy because it is used only by the system. Using fragments considerably reduces the amount of unused, wasted disk space.

The AdvFS and AdvFS Utilities products are separately licensed products. AdvFS is a file-system option on the Digital UNIX operating system. The AdvFS Utilities product provides additional capabilities and is offered as a layered product.

These products have the following separate software-license policies:

• License Registration for the POLYCENTER Advanced File System
  If you registered the Digital UNIX operating system license product authorization key (PAK), then you can install and use AdvFS base functions. See the Guide to Installing Digital UNIX for instructions on installing AdvFS.
• License Registration for the POLYCENTER Advanced File System Utilities
  Before you can use the file-system utilities, you must register a license product authorization key (PAK) for the POLYCENTER Advanced File System Utilities. Contact your Digital representative for additional information.