vxupgrade (1M)


vxupgrade - upgrade the disk layout of a mounted VxFS file system


vxupgrade [-n new_version] [-r rawdev] mount_point




vxupgrade prints the current disk layout version number for a Veritas File System or upgrades the file system to a new disk layout. vxupgrade operates on file systems mounted for read/write access: mount_point must be a mounted VxFS file system. You cannot upgrade directly from the oldest disk layout version to the newest disk layout version; you must upgrade to each successive disk layout version, one at a time.

Only a privileged user can query or upgrade a VxFS file system.

When invoked with the -n option, vxupgrade upgrades the disk layout to the specified version. When invoked without the -n option, vxupgrade prints the disk layout version number of the file system. To perform an upgrade, vxupgrade freezes the file system, allocates and initializes the new structures, frees the space used by the old structures, then thaws the file system.

vxupgrade employs a lock file (lost+found/.fsadm) on the file system to ensure that only one instance of vxupgrade is running at any time. vxupgrade and fsadm cannot run simultaneously, so the lock file also ensures that vxupgrade does not execute while a file system reorganization is in progress. When vxupgrade is invoked for an upgrade, it opens the lock file in the root of the file system specified by mount_point. If the lock 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, vxupgrade fails, assuming that another vxupgrade or fsadm is running.


Disk layout versions cannot be downgraded.

Each version upgrade requires a separate invocation of the vxupgrade command. This command upgrades disk layout Version 4 directly to Version 6, since disk layout Version 5 does not exist in the VxFS release on the  A IX operating system. For example, to upgrade from disk layout Version 4 to Version 7, you must upgrade to Version 6 first, then 7. The upgrade may fail due to lack of free space at each step.

When upgrading disk layout Version 6 to Version 7 or Version 7 to Version 8 on a multi-volume file system, Symantec recommends that you have at least 16 MB of free space on volume 0.

Upgrading from disk layout Version 4 to Version 6 changes all inodes in the file system.

Optionally, prior to upgrading a file system from disk layout Version 4 to disk layout Version 6, delete some or all existing Storage Checkpoints. A Storage Checkpoint created on a file system with a disk layout prior to Version 6 stores a complete copy of the inodes at the time it was taken. Thus, a file system with one Storage Checkpoint takes approximately twice as long to upgrade than a file system without Storage Checkpoints. Conversely, a Storage Checkpoint created on a file system with disk layout Version 6 or later stores only the inodes of files whose data blocks were modified. As a result, the time required to upgrade the disk layout Version in the future is less affected by the number of Storage Checkpoints on the file system.

Symantec recommends that you upgrade from disk layout Version 6 to Version 7 or 8. Disk layout Version 6 will be deprecated in the next major release.

Cluster File System Issues

Cluster mounted file systems can be upgraded only from the primary.


vxupgrade returns an exit value of 0 if the upgrade is successful. vxupgrade returns 1 if the upgrade fails due to insufficient free space, returns 32 if the specified mount point is not a VxFS file system, and returns 2 if the upgrade fails for another reason.


-n new_version Disk layout version number to which to upgrade. new_version can be 6 or 7.
-r rawdev Path name of a raw device. This option can be used when vxupgrade cannot determine which raw device corresponds to the mount point, such as when /etc/mnttab is corrupted.

Free Space Requirement

vxupgrade requires free space on the file system to perform the upgrade; the upgrade may fail if there is not enough free space. It is difficult to determine the exact amount of space required to upgrade a VxFS file system, but you can estimate the maximum space required.

The space and time required to complete the upgrade increases with the number of extended attributes or hard links in the file system. The typical maximum space required to convert to a Version 6 or 7 disk layout is at least two inodes more than the sum total of inodes across all filesets in the file system. Each inode requires one block. Allow at least ten minutes to upgrade for every million inodes in the file system.

The typical maximum space required to convert to the Version 8 disk layout is similar to upgrading to the Version 7 disk layout, but vxupgrade also creates an extra inode per device and creates a reference count queue (RCQ) file. In the case of a cluster file system, vxupgrade creates one RCQ file per node. The RCQ file size depends on the file system size, as shown on the following table:

File system size RCQ size ---------------- -------- 0 MB to 16 GB 1 MB 16 GB to 32 GB 2 MB 32 GB to 128 GB 4 MB 128 GB to 512 GB 8 MB 512 GB to 1 TB 16 MB 1+ TB 64 MB
Upgrading requires free extents of 8K or greater in size. If a file system has sufficient free space, but no extents greater than or equal to 8K, the upgrade will fail. To ensure that there are 8K extents available, defragment the file system. See the fsadm_vxfs(1M) manual page for information on how to obtain the number of free extents in a file system and how to defragment a file system.


mount_point/lost+found/.fsadm Lock file.


fcntl, fsadm_vxfs(1M), mkfs_vxfs(1M), vxquotaon(1M), vxfsconvert(1M), vxfsio(7)

Veritas File System Administrator’s Guide

VxFS 5.1 SP1 vxupgrade (1M)