The following specific_options are valid on a VxFS file system:
VxFS 3.2 contains new features that are incompatible with earlier versions of some operating systems 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 4 disk layout, available in VxFS 3.2 and above, so an older operating system running a previous version of VxFS would 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 flag is provided that allows or prevents the creation of large files on the file system. If the largefile compatibility flag 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. If the largefiles flag is set on a file system, files can be created that are larger than 2 Gbytes in size.
An attempt to set the flag via the -o largefiles option will succeed only if the file system has the Version 4 disk layout (see the vxupgrade(1M) manual page to upgrade a file system from the Version 1 or later disk layout to the Version 4 disk layout). An attempt to clear the flag via the -o nolargefiles option will succeed only if the flag is set and there are no large files present on the file system (see mount_vxfs(1M).
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.
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.
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 /var
Directory Fragmentation Report
Dirs Total Immed Immeds Dirs to Blocks to
Searched Blocks Dirs to Add Reduce Reduce
total 486 99 388 6 6 6
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.
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 -D command:
# fsadm -d -D /optDirectory Fragmentation Report Dirs Total Immed Immeds Dirs to Blocks to Searched Blocks Dirs to Add Reduce Reduce total 486 94 393 1 1 1 Directory Fragmentation Report Dirs Total Immed Immeds Dirs to Blocks to Searched Blocks Dirs to Add Reduce Reduce total 486 93 394 0 0 0
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.
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.
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 /home
Extent Fragmentation Report
Total Average Average Total
Files File Blks # Extents Free Blks
939 11 2 245280
blocks used for indirects: 0
% Free blocks in extents smaller than 64 blks: 8.35
% Free blocks in extents smaller than 8 blks: 4.16
% blks allocated to extents 64 blks or larger: 45.81
Free Extents By Size
1: 356 2: 292 4: 271 8: 181
16: 23 32: 7 64: 3 128: 1
256: 1 512: 0 1024: 1 2048: 1
4096: 2 8192: 2 16384: 1 32768: 2
The numbers in the column labeled ''Total Files'' indicate the total number of files that have data extents.
The column labeled ''Average File Blks'' contains the average number of blocks belonging to all files.
The column labeled ''Average # Extents'' contains the average number of extents used by files in the file system.
The column labeled ''Total Free Blks'' contains the total number of free blocks in the file system.
The total number of blocks used for indirect address extent are reported as ''blocks used for indirects''.
The general shape of free extent map is reported as well. There are two percentages reported, % free extents smaller than 64 blocks and % free extents smaller than 8 blocks. These numbers should approach 0 on an unfragmented file system.
Another metric which is reported is the percentage of blocks that are part of extents 64 blocks or larger. Files with a single small extent are not included in this calculation. This number should be large on file systems that contain many large files, and will probably be small on file systems that contain many small files.
The figures under the heading ''Free Extents By Size'' indicate the 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 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 can improve 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.
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.
fsadm attempts to reduce both file fragmentation and free extent fragmentation in each pass. In previous versions of fsadm, considerable effort was made to obtain an ''optimal'' file system layout. This version of fsadm relies on the ability of the VxFS kernel allocation mechanisms to cause files to be reallocated in a more favorable extent geometry. At the same time, the kernel allocation mechanism is prevented from using blocks in areas of the free list that fsadm would like to make more contiguous.
The command line to perform extent reorganization is
fsadm -F vxfs -e [-sv] [-p passes] [-t time] [-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 /mnt1
Extent Fragmentation Report
Total Average Average Total
Files File Blks # Extents Free Blks
939 11 2 245280
blocks used for indirects: 0
% Free blocks in extents smaller than 64 blks: 8.35
% Free blocks in extents smaller than 8 blks: 4.16
% blks allocated to extents 64 blks or larger: 45.81
Free Extents By Size
1: 356 2: 292 4: 271 8: 181
16: 23 32: 7 64: 3 128: 1
256: 1 512: 0 1024: 1 2048: 1
4096: 2 8192: 2 16384: 1 32768: 2
Pass 1 Statistics
Extents Reallocations Ioctls Errors
Searched Attempted Issued FileBusy NoSpace Total
total 2016 1473 789 0 0 0
Pass 2 Statistics
Extents Reallocations Ioctls Errors
Searched Attempted Issued FileBusy NoSpace Total
total 1836 0 0 0 0 0
Extent Fragmentation Report
Total Average Average Total
Files File Blks # Extents Free Blks
939 11 1 245280
blocks used for indirects: 0
% Free blocks in extents smaller than 64 blks: 0.46
% Free blocks in extents smaller than 8 blks: 0.03
% blks allocated to extents 64 blks or larger: 45.53
Free Extents By Size
1: 10 2: 1 4: 1 8: 4
16: 3 32: 4 64: 3 128: 3
256: 3 512: 4 1024: 4 2048: 2
4096: 3 8192: 1 16384: 1 32768: 2
Note that the default five passes were scheduled, but the reorganization finished in two passes.
This file system had a significant amount of free space, though there were quite few free small extents. This situation was corrected by reallocating one or more of the extents on many of the files in the file system. The files that would be selected for reallocation in this case are those with extents in the heavily fragmented section of the allocation units. The time it takes to complete extent reorganization varies, depending on fragmentation and disk speeds and the number of inodes in the file system. However, in general, extent reorganization may be expected to take approximately one minute for every 100 megabytes of disk space used.
In the preceding example, the column labeled "Extents Searched" contains the total number of extents examined. The column labeled "Reallocations Attempted" contains the total number of consolidations or merging of extents performed. The column labeled "Ioctls Issued" contains the total number of reorganization requests calls made during the pass. This corresponds closely to the number of files that were being operated on in that pass since most files are able to be reorganized with a single ioctl. (More than one extent may be consolidated in one operation.) The column labeled "File Busy" (located under the heading "Errors") contains the total number of reorganization requests that failed because the file was active during reorganization. The column labeled "NoSpace" (located under the heading "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 "Total" (located under the heading "Errors") is the total number of errors encountered during the reorganization and may include some errors that were not included with "FileBusy" or "NoSpace".