Using fsadm to measure and optimize extent and directory fragmentation

Article: 100024882
Last Published: 2014-01-15
Ratings: 1 0
Product(s): InfoScale & Storage Foundation

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.
 


Note: This article assumes a VxFS filesystem.






Measuring Extent Fragmentation

(Back to top)


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

  Extent Fragmentation Report
        Total    Average      Average     Total
        Files    File Blks    # Extents   Free Blks
      2336955        1777           2   516009975
    blocks used for indirects: 400112
    % 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
    Free Extents By Size
           1:     478501            2:     580631            4:     670905
           8:     555934           16:     518327           32:     503185
          64:     493497          128:     491920          256:     493497
         512:     385151         1024:       9204         2048:      14088
        4096:       4166         8192:        952        16384:         99
       32768:          0        65536:          0       131072:          0
      262144:          0       524288:          0      1048576:          0
     2097152:          0      4194304:          0      8388608:          0
    16777216:          0     33554432:          0     67108864:          0
   134217728:          0    268435456:          0    536870912:          0
  1073741824:          0   2147483648:          0

 

 

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

(Back to top)



Figure 2


Syntax:

/opt/VRTS/bin/fsadm -D <mount_point>


Example, with typical output:

#/opt/VRTS/bin/fsadm -D /myfs

  Directory Fragmentation Report
             Dirs        Total      Immed    Immeds   Dirs to   Blocks to
             Searched    Blocks     Dirs     to Add   Reduce    Reduce
  total        122964    398297      5731     65141     85233      237722

 

 

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

Directory Reorganization Statistics
Dirs Dirs Total Failed Blocks Blocks Immeds
Searched Changed Ioctls Ioctls Reduced Changed Added
fset 999 5779 828 828 0 9005 24666 115
total 5779 828 828 0 9005 24666 115

Pass 1 Statistics
Extents Reallocations Ioctls Errors
Searched Attempted Issued FileBusy NoSpace Total
total 236242 65860 48303 0 0 0

 

 


Was this content helpful?