fsadm_vxfs(1M)

Options

File-System Compatibility Bits

The -o largefiles and -o nolargefiles options can be used to change the largefile compatibility bit. When invoked without options fsadm prints the current state of the compatibility bits.

VxFS 3.0 has some new features that are incompatible with earlier versions of HP-UX and with old applications. These features are large files (file sizes greater than 2 Gbyte), and hierarchical storage management via the DMAPI (Data Management Applications Programming Interface).

Large files are available only with the Version 3 disk layout, available in VxFS 3.0 and above, so an old version of HP-UX will never be exposed to them (the file-system mount would fail). But many existing applications will break if confronted with large files, so a compatibility bit is provided that allows or prevents the creation of large files on the file system. If the largefile compatibility bit is set, large files may be created on the file system. If it is not set, any attempt to create a large file on the file system will fail.

An attempt to set the bit via the -o largefiles option will succeed only if the file system has the Version 3 disk layout (see the vxupgrade(1M) manual page to upgrade a file system from the Version 2 disk layout to the Version 3 disk layout). An attempt to clear the bit via the -o nolargefiles option will succeed only if the bit is set and there are no large files present on the file system. (Also see the mount_vxfs(1M) manual page).

The -o largefiles and -o nolargefiles options are the only fsadm options that can be used on an unmounted file system. An unmounted file system can be specified by invoking fsadm with a special device rather than a mount point. If an unmounted file system is specified, it must be clean.

The DMAPI compatibility bit cannot be changed by fsadm; it can only be queried. If set, it indicates that the file system is mounted, or has been mounted, under the control of the Hierarchical Storage Management software and cannot be mounted unless that software is active on the system.

Defragmentation

For optimal performance, the kernel-extent allocator must be able to find large extents when it wants them. To maintain file-system performance, fsadm should be run periodically against all VxFS file systems to reduce fragmentation. fsadm should be run somewhere between once a day and once a month against each file system. The frequency depends on file system usage and activity patterns, and the importance of performance. The -v option can be used to examine the amount of work performed by fsadm. The frequency of reorganization can be adjusted based on the rate of file system fragmentation.

There are two options that are available to control the amount of work done by fsadm. The -t option is used to specify a maximum length of time to run. The -p option is used to specify a maximum number of passes to run. If both are specified, the utility exits if either of the terminating conditions is reached. By default, fsadm will run 5 passes. If both the -e and -d options are specified, the utility will run all the directory reorganization passes before any extent reorganization passes.

fsadm uses the file .fsadm in the lost+found directory as a lock file. When fsadm is invoked, it opens the file lost+found/.fsadm in the root of the file system specified by mount_point. If the file does not exist, it is created. The fcntl(2) system call is used to obtain a write lock on the file. If the write lock fails, fsadm will assume that another fsadm is running and will fail. fsadm will report the process ID of the process holding the write lock on the .fsadm file.

File System Resizing

If the -b option is specified, fsadm will resize the file system whose mount point is mount_point. If newsize is larger than the current size of the file system, the file system will be expanded to newsize sectors. Similarly, if newsize is smaller than the current size of the file system, an attempt will be made to shrink the file system to newsize sectors.

Increasing the size of a file system requires that the file system contains enough free space, prior to the expansion, for the growth of the structural files. In the case where a filesystem has no free blocks available, the attempt to increase the size of the file system will fail (see the extendfs(1M) manual page for an alternate method to increase file system size).

Reducing the size of a file system will fail if there are file-system resources currently in use within the sectors to be removed from the file system. In this case, a reorganization may help free those busy resources and allow a subsequent reduction in the size of the file system.

Reporting on Directory Fragmentation

As files are allocated and freed, directories tend to grow and become sparse. In general, a directory is as large as the largest number of files it ever contained, even if some files have been subsequently removed.

The command line to obtain a directory fragmentation report is:

fsadm [-D] [-r rawdev] mount_point

The following is some example output from the fsadm -D command:

# fsadm -D /lhome

The column labeled "Dirs Searched" contains the total number of directories. A directory is associated with the extent-allocation unit containing the extent in which the directory's inode is located. The column labeled "Total Blocks" contains the total number of blocks used by directory extents.

The column labeled "Immed Dirs" contains the number of directories that are immediate, meaning that the directory data is in the inode itself, as opposed to being in an extent. Immediate directories save space and speed up pathname resolution. The column labeled "Immeds to Add" contains the number of directories that currently have a data extent, but that could be reduced in size and contained entirely in the inode.

The column labeled "Dirs to Reduce" contains the number of directories for which one or more blocks could be freed if the entries in the directory are compressed to make the free space in the directory contiguous. Since directory entries vary in length, it is possible that some large directories may contain a block or more of total free space, but with the entries arranged in such a way that the space cannot be made contiguous. As a result, it is possible to have a nonzero "Dirs to Reduce" calculation immediately after running a directory reorganization. The -v (verbose) option of directory reorganization reports occurrences of failure to compress free space.

The column labeled "Blocks to Reduce" contains the number of blocks that could be freed if the entries in the directory are compressed.

Measuring Directory Fragmentation

If the totals in the columns labeled "Dirs to Reduce" are substantial, a directory reorganization should improve performance of pathname resolution. The directories that fragment tend to be the directories with the most activity. A small number of fragmented directories may account for a large percentage of name lookups in the file system.

Directory Reorganization

If the -d option is specified, fsadm will reorganize the directories on the file system whose mount point is mount_point. Directories are reorganized in two ways: compression and sorting.

For compression, the valid entries in the directory are moved to the front of the directory and the free space is grouped at the end of the directory. If there are no entries in the last block of the directory, the block is released and the directory size is reduced.

If the directory entries are small enough, the directory will be placed in the inode immediate data area.

The entries in a directory are also sorted to improve pathname lookup performance. Entries are sorted based on the last access time of the entry. The -a option is used to specify a time interval; 14 days is the default if -a is not specified. The time interval is broken up into 128 buckets, and all times within the same bucket are considered equal. All access times older than the time interval are considered equal, and those entries are placed last. Subdirectory entries are placed at the front of the directory and symbolic links are placed after subdirectories, followed by the most-recently-accessed files.

The directory reorganization runs in one pass across the entire file system.

The command line to reorganize directories of a file system is:

fsadm -d [-s] [-v] [-p passes] [-t timeout] [-r rawdev] [-D] mount_point

The following example illustrates the output of the command fsadm -d -s command:

# fsadm -d -s /lhome

The column labeled "Dirs Searched" contains the number of directories searched. Only directories with data extents are reorganized. Immediate directories are skipped. The column labeled "Dirs Changed" contains the number of directories for which a change was made.

The column labeled "Total Ioctls" contains the total number of VX_DIRSORT ioctls performed. Reorganization of directory extents is performed using this ioctl.

The column labeled "Failed Ioctls" contains the number of requests that failed for some reason. The reason for failure is usually that the directory being reorganized is active. A few failures should be no cause for alarm. If the -v option is used, all ioctl calls and status returns are recorded.

The column labeled "Blocks Reduced" contains the total number of directory blocks freed by compressing entries. The column labeled "Blocks Changed" contains the total number of directory blocks updated while sorting and compressing entries.

The column labeled "Immeds Added" contains the total number of directories with data extents that were compressed into immediate directories.

Reporting on Extent Fragmentation

As files are created and removed over time, the free extent map for an allocation unit will change from having one large free area to having many smaller free areas. This process is known as fragmentation. Also, when files are grown — particularly when growth occurs in small increments — small files could be allocated in multiple extents. In the ideal case, each file that is not sparse would have exactly one extent (containing the entire file), and the free-extent map would be one continuous range of free blocks.

Conversely, in a case of extreme fragmentation, there can be free space in the file system, none of which can be allocated. For example, on Version 2 VxFS file systems, the indirect-address extent size is always 8K long. This means that to allocate an indirect-address extent to a file, an 8K extent must be available. For example, if no extent of 8K byes or larger is available, even though more than 8K of free space is available, an attempt to allocate a file into indirect extents will fail and return ENOSPC.

Determining Fragmentation

To determine whether fragmentation exists for a given file system, the free extents for that file system need to be examined. If a large number small extents are free, then there is fragmentation. If more than half of the amount of free space is taken up by small extents (smaller than 64 blocks), or there is less than 5 percent of total file system space available in large extents, then there is serious fragmentation.

Running the Extent-Fragmentation Report

The extent-fragmentation report can be run to acquire detailed information about the degree of fragmentation in a given file system.

The command line to run an extent-fragmentation report is

fsadm -E [-l largesize] [-r rawdev] mount_point

The extent reorganizer has the concept of an immovable extent: if the file already contains large extents, reallocating and consolidating these extents will not improve performance, so they are considered immovable. fsadm's notion of how large an extent must be to qualify as immovable can be controlled by the -l option. By default, largesize is 64 blocks, meaning that any extent larger than 64 blocks is considered to be immovable. For the purposes of the extent-fragmentation report, the value chosen for largesize will affect which extents are reported as being immovable extents.

The following is an example of the output generated by the fsadm -E command:

# fsadm -E /lhome

The numbers in the column labeled ``Files with Extents'' indicate the total number of files that have data extents. A file is considered to be in the extent-allocation unit that contains the extent holding the file's inode.

The column labeled ``Total Extents'' contains the total number of extents belonging to files in the allocation unit. The extents themselves are not necessarily in the same allocation unit.

The column labeled ``Total Blocks'' contains the total number of blocks used by files in the allocation unit. If the total number of blocks is divided by the total number of extents, the resulting figure is the average extent size.

The column labeled ``Total Distance'' contains the total distance between extents in the allocation unit. For example, if a file has two extents, the first containing blocks 100 through 107 and the second containing blocks 110 through 120, the distance between the extents is 110-107, or 3. In general, a lower number means that files are more contiguous. If an extent reorganization is run on a fragmented file system, the value for Total Distance should be reduced.

The column labeled ``Consolidatable Extents'' contains the number of extents that are candidates to be consolidated. Consolidation means merging two or more extents into one combined extent. For files that are entirely in direct extents, the extent reorganizer will attempt to consolidate extents into extents up to size largesize. All files of size largesize or less will typically be contiguous in one extent after reorganization. Since most files are small, this will usually include about 98 percent of all files.

The column labeled ``Consolidatable Blocks'' contains the total number of blocks in Consolidatable Extents. The column labeled ``Immovable Extents'' contains the total number of extents that are considered to be immovable. In the report, an immovable extent appears in the allocation unit of the extent itself, as opposed to in the allocation unit of its inode. This is because the extent is considered to be immovable, and thus permanently fixed in the associated allocation unit.

The column labeled ``Immovable Blocks'' contains the total number of blocks in immovable extents. The figures under the heading ``Free Extents By Size'' indicate per-allocation unit totals for free extents of each size. The totals are for free extents of size 1, 2, 4, 8, 16, ... up to a maximum of the number of data blocks in an allocation unit. The totals should match the output of df -o s unless there has been recent allocation or deallocation activity (as this utility acts on mounted file systems). These figures give an indication of fragmentation and extent availability on a per-allocation-unit basis. For each allocation unit, and for the complete file system, the total free blocks and total free blocks by category are shown. The figures are presented as follows:

In the preceding example, 4 percent of free space is in extents less than 8 blocks in length, and 24 percent of the free space is in extents less than 64 blocks in length. This represents a typical value for a mature file system that is regularly reorganized. The total free space is about 10 percent.

Extent Reorganization

If the -e option is specified, fsadm will reorganize the data extents on the file system whose mount point is mount_point. The primary goal of extent reorganization is to defragment the file system.

To reduce fragmentation, extent reorganization tries to place all small files in one contiguous extent. The -l option is used to specify the size of a file that is considered large. The default is 64 blocks. Extent reorganization also tries to group large files into large extents of at least 64 blocks. In addition to reducing fragmentation, extent reorganizations improves performance. Small files can be read or written in one I/O operation. Large files can approach raw-disk performance for sequential I/O operations.

Extent reorganization also tries to improve the locality of reference on the file system. Extents are moved into the same allocation unit as their inode. Within the allocation unit, small files and directories are migrated to the front of the allocation unit. Large files and inactive files are migrated towards the back of the allocation unit. (A file is considered inactive if the access time on the inode is more than 14 days old. The time interval can be varied using the -a option.) Extent reorganization should reduce the average seek time by placing inodes and frequently used data closer together.

fsadm will try to perform extent reorganization on all inodes on the file system. Each pass through the inodes will move the file system closer to the organization considered optimal by fsadm. The first pass might place a file into one contiguous extent. The second pass might move the file into the same allocation unit as its inode. Then, since the first file has been moved, a third pass might move extents for a file in another allocation unit into the space vacated by the first file during the second pass.

When the file system is more than 90% full, fsadm shifts to a different reorganization scheme. Instead of attempting to make files contiguous, extent reorganization tries to defragment the free-extent map into chunks of at least 64 blocks or the size specified by the -l option.

The command line to perform extent reorganization is

fsadm -F vxfs -e [-sv] [-p passes] [-t time] [-a days] [-l largesize] [-r rawdev] mount_point

The following example illustrates the output from the fsadm -F vxfs -e -s command:

# fsadm -F vxfs -e -s /lhome

Note that the default five passes were scheduled, but the reorganization finished in two passes.

This file system had not had much activity since the last reorganization, with the result that little reorganization was required. The time it takes to complete extent reorganization varies, depending on fragmentation and disk speeds. However, in general, extent reorganization may be expected to take approximately one minute for every 10 megabytes of disk space used.

In the preceding example, the column labeled ``Extents Searched'' contains the total number of extents examined. The column labeled ``Number'' (located under the heading ``Consolidations Performed'') contains the total number of consolidations or merging of extents performed. The column labeled ``Extents'' (located under the heading ``Consolidations Performed'') contains the total number of extents that were consolidated. (More than one extent may be consolidated in one operation.) The column labeled ``Blocks'' (located under the heading ``Consolidations Performed'') contains the total number of blocks that were consolidated.

The column labeled ``File Busy'' (located under the heading ''Total Errors'') contains the total number of reorganization requests that failed because the file was active during reorganization. The column labeled ``Not Free'' (located under the heading ``Total Errors'') contains the total number of reorganization requests that failed because an extent that the reorganizer expected to be free was allocated at some time during the reorganization.

The column labeled ``In Proper Location'' contains the total extents and blocks that were already in the proper location at the start of the pass. The column labeled ``Moved to Proper Location'' contains the total extents and blocks that were moved to the proper location during the pass.

The column labeled ``Moved to Free Area'' contains the total number of extents and blocks that were moved into a convenient free area in order to free up space designated as the proper location for an extent in the allocation unit being reorganized. The column labeled ``In Free Area'' contains the total number of extents and blocks that were in areas designated as free areas at the beginning of the pass.

The column labeled ``Could not be Moved'' contains the total number of extents and blocks that were in an undesirable location and could not be moved. This occurs when there is not enough free space to allow sufficient extent movement to take place. This often occurs on the first few passes for an allocation unit if a large amount of reorganization needs to be performed.

If the next to the last pass of the reorganization run indicates extents that cannot be moved, then the reorganization fails. A failed reorganization may leave the file system badly fragmented, since free areas are used when trying to free up reserved locations. To lessen this fragmentation, extents are not moved into the free areas on the final two passes of the extent reorganizer, and the last pass of the extent reorganizer only consolidates free space.

Notes

The online reorganization and online resize features of fsadm are available only with the Advanced VxFS package.