Problem
Using fsadm to measure and optimize extent and directory fragmentation.
Solution
This article is a part of a set on troubleshooting volume performance. Click here to start at the beginning: https://www.veritas.com/docs/000087750 |
Table of Contents
Introduction
Measuring Extent Fragmentation
Measuring Directory Fragmentation
Using fsadm to optimize the file system
Introduction
(Back to top)
Filesystem fragmentation causes data blocks to be scattered through a filesystem in a non-contiguous manner. This reduces performance by increasing the amount of time and movement that is required to access data blocks and reduces performance. When troubleshooting performance, use /opt/VRTS/bin/fsadm to check for VxFS filesystem fragmentation.
Measuring Extent Fragmentation
An extent is a contiguous region of disk space defined in the file system's allocation unit map. VxFS assigns space to files in terms of extents.
More details about extent-based allocation can be found here:
"About extent-based allocation" (from the Veritas Storage Foundation 5.0 Administrators Guide)
https://sort.Veritas.com/public/documents/sf/5.0/linux/html/fs_admin/ag_ch_intro_fs7.html
Use /opt/VRTS/bin/fsadm -E to determine the level of extent fragmentation for a file system (Figure 1).
Figure 1
Syntax: /opt/VRTS/bin/fsadm -E <mount_point> Example, with typical output: # /opt/VRTS/bin/fsadm -E /myfs |
The example in Figure 1 shows the following information:
- There are 2,336,955 files in this file system
- The average number of blocks used by each file is 1777
- Each file on average is using 2 extents
- 516,009,975 blocks are free
- 400,112 blocks are being used for extended inode addresses
The first key to file system health is the average number of extents. This number will be highly dependent on the kind of data storage being performed on this file system, but it can give a hint as to the efficiency of the file system's extent allocations. Larger files will require more extents overall, smaller files will require smaller extents. In the case of a few large files, a larger average here is normal. In the case of many small files here, the expectation for tolerable extents show be lower. For this example, 2.3 million files with an average extent size of 2 is extremely good and represents good file system health.
Notice the following lines:
% Free blocks in extents smaller than 64 blks: 6.43
% Free blocks in extents smaller than 8 blks: 0.84
% blks allocated to extents 64 blks or larger: 99.60
These lines show the following:
- How many free (unallocated) blocks are part of extents smaller than 64 blocks
- How many free blocks are part of extents smaller than 8 blocks
- Overall % of blocks in the file system part of extents 64 blocks or larger (free or in-use)
The first two lines represent free space fragmentation. The higher the percentages, the more fragmented the file system. The first line is a medium level warning -- for smaller files (512k or less) 64 block extents do not represent fragmentation. If the file system is used for larger files such as databases then a high percentage here could have performance impacts. A significant percentage value for the "8 block extents or smaller line" would indicate serious fragmentation and would mean defragmentation should be performed as a priority.
Table 1 can be used as a general guideline for determining when extent fragmentation is expected to degrade performance. In general, a file system showing over 20% free blocks in extents smaller than 8 blocks should be considered critical and requiring immediate defragmentation.
Table 1 - Guidelines for extent fragmentation
Percentage | Unfragmented | Badly Fragmented |
% of Free blocks in extents < 64 blocks | < 5% | > 50% |
% of Free blocks in extents < 8 blocks | < 1% | > 5% |
% blks allocated to extents 64 blks or larger | > 5% | < 5% |
Measuring Directory Fragmentation
Figure 2
Syntax: /opt/VRTS/bin/fsadm -D <mount_point> Example, with typical output: #/opt/VRTS/bin/fsadm -D /myfs |
The output above shows the following information:
- 122,964 directories in this file system
- 398,297 blocks used by directories in this file system
- 85,233 directories are using more space than needed for file indexing
- 237,722 blocks can be recovered by performing a directory defragmentation
VxFS directories use blocks associated with the directory inode to store file lists and indexes. As files are added to a directory more blocks will be allocated as necessary. If those files are then removed, the directory does not automatically release that extra space.
The command "fsadm -d <mountpoint>" will adjust directories and recover those unnecessary blocks.
The "immed" columns reference immediate directory usage, which uses space inside the directory inode for file indexing -- these directories have few enough files that the index can fit inside the extra 96 bytes in the directory inode. The output above shows that 5731 directories are currently immediate type, and following a "-d" defrag operation 65,141 directories will be coverted to immediate as well.
This layer of the defragmentation data is purely diskspace related. Directory fragmentation rarely produces noticeable performance impacts or issues.
Using fsadm to optimize the file system
(Back to top)
Use /opt/VRTS/bin/fsadm to optimize the file system (Figure 3). This includes defragmenting both the directories and extents. The "-t" argument can be used to specify a number of "passes."
Figure 3
Syntax: /opt/VRTS/bin/fsadm -ed -s <mountpoint> Example, with typical output: # /opt/VRTS/bin/fsadm -ed -s /engvol |