Shrinking a VERITAS File System (VxFS) file system - considerations for success

Article:TECH4568  |  Created: 2000-01-10  |  Updated: 2004-01-21  |  Article URL
Article Type
Technical Solution



Shrinking a VERITAS File System (VxFS) file system - considerations for success


This document will consider an actual example of shrinking an existing file system. Even if a file system is not currently close to full, if files were ever created when the file system was relatively full, and those files still exist in the file system, there likely are used blocks nearer the end of the current file system object. The following discussion about shrinking a file system has this scenario in mind:

The file system is first 97% full, then it is reduced to 53% full. Then fsadm is run to reorganize the file system. This is an important step to free space and reduce fragmentation at the end of the file system, so that those blocks may be removed from the file system. After this, when fsadm is run to shrink the file system, it fails, saying that inodes and blocks are still in use.
Is there something else to be done while doing this?

As the error states, there are structures in use in the Allocation Units (AUs) that should be removed or truncated. However, there are some possibilities:

- If there are blocks in use, then a reorganization of the file system might help. Try using the standard:
fsadm -ed
And then try shrinking it again.

- If this does not work, try a more aggressive reorganization:

fsadm -p 20 -l 2048 -a 3000 -e

This will do 20 passes, attempting to move any extents of size 2048 blocks or smaller and any extents belonging to a file that is newer than 3000 days to the front of an AU. Then try shrinking the file system again.

If it is still impossible to shrink the file system, then there must be an inode in use in one of the AUs where an attempt is made to remove or truncate it. Inodes cannot be moved online the way that extents can. It is necessary to find out which inodes are in use and attempt to "move" them to another AU. If this still does not work, attempt a smaller shrink, and increment your file system shrink operations.

It is apparent then that this needs to be assessed on a case by case basis and it is possible to have a worst case. Worst case would require an iterative approach or, if all else fails, backup, mkfs and restore.

In a Version 4 disk layout, if there are file system resources in use in the sectors being removed, fsadm relocates those resources to sectors staying within the resized file system. The time needed for relocation depends on the number of blocks being moved.

In older disk layout versions, file system structural components are fixed, so reducing the size of a file system fails if there are file system resources in use in the sectors being removed. In that case, a reorganization (using fsadm -e ) can free busy resources and allow shrinking the file system. If there are still file system structural components within the area to be removed, the file system must be upgraded to a Version 4 disk layout to do a resize (see the vxupgrade(1M) manual page).

For optimal performance, the kernel-extent allocator must be able to find large extents when it wants them. To maintain file system performance, run fsadm periodically against all VxFS file systems to reduce fragmentation. The frequency depends on file system usage and activity patterns, and the importance of performance; typically between once a day and once a month against each file system. 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.

See the fsadm_vxfs(1M) manual page for more information.

Legacy ID


Article URL

Terms of use for this information are found in Legal Notices