Grow a Mounted XFS Filesystem Safely with xfs_growfs

Once the disk underneath has been expanded, xfs_growfs is what makes that new space usable by the existing, still-mounted XFS filesystem. The filesystem must already be mounted, and the device, logical volume or partition underneath it must have been expanded first. Existing files are left in place; the extra capacity becomes available for new data.

On this machine, the installed xfsprogs package is version 6.6.0-1ubuntu2.1 and xfs_growfs reports version 6.6.0. Allow a few minutes for checks and verification. The filesystem resize itself is normally quick, but the storage-layer change and any maintenance window are separate work.

Before you start

• Confirm the target is XFS and note its mount point.
• Confirm the backing storage has already grown. xfs_growfs does not enlarge an LV, partition, virtual disk or physical device.
• Have a current backup or a recovery plan. Growing is designed to preserve data, but a storage change is still an administrative operation.
• Have elevated privileges available. Reading mount information is usually unprivileged; changing filesystem geometry normally needs root.

1. Identify the mounted XFS filesystem

Replace the example path with the directory whose filesystem you intend to grow. This read-only command shows the source, filesystem type and capacity:

findmnt -T /srv/data -o TARGET,SOURCE,FSTYPE,SIZE,USED,AVAIL

Expected output has xfs in the FSTYPE column and identifies the backing source:

TARGET    SOURCE             FSTYPE  SIZE  USED  AVAIL
/srv/data /dev/mapper/vg-data xfs     200G   80G   120G

If the type is not XFS, stop: this guide is not a recipe for resizing another filesystem. If the command does not show a mounted filesystem at that path, correct the path or mount it according to your normal operating procedure.

2. Check that the storage layer is ready

Compare the size reported by the storage layer with the size visible to the filesystem. For an LVM logical volume, this is a read-only inspection:

sudo lvs -o lv_path,lv_size,vg_name /dev/vg/data
sudo xfs_info /srv/data

The first command reports the LV size. The second reports XFS geometry, including data blocks and allocation groups. If the LV or virtual disk has not grown, stop here and expand it using the procedure for your storage provider. For LVM, that is commonly an approved lvextend change, but the exact command and approval belong to your storage configuration.

Do not run an LV or partition resize merely because xfs_growfs is the next step. A wrong device, wrong size or wrong partition boundary can cause data loss and cannot be undone by xfs_growfs.

3. Preview the XFS geometry

Run the no-change mode against the mount point:

sudo xfs_growfs -n /srv/data

The -n option performs argument checking and prints filesystem geometry without growing anything. Use this checkpoint to confirm that the command accepts the mounted filesystem and that its reported data area is consistent with the capacity you expect. Keep the output with your change record if the operation is part of a production change.

On this machine, running the same check against the root filesystem produces xfs_growfs: / is not a mounted XFS filesystem because root is not XFS. That is the expected failure for a non-XFS target, not evidence that the command is broken.

4. Grow the data section to the available size

For the ordinary case, ask XFS to use the largest possible data area:

sudo xfs_growfs -d /srv/data

The command changes filesystem geometry, so expect a zero exit status and a geometry report. The filesystem stays mounted. Existing contents are not moved or deleted, and the added space is available for subsequent file creation.

There is no general undo command for this operation. If the backing device was enlarged by mistake, stop and use your storage and backup recovery procedures. Do not try to make up a smaller value with -D as an emergency rollback.

5. Verify the capacity from two views

Check both the filesystem view and the storage mapping:

findmnt -T /srv/data -o TARGET,SOURCE,FSTYPE,SIZE,USED,AVAIL
df -hT /srv/data
sudo xfs_info /srv/data

df should show the larger usable size while still identifying the filesystem as XFS. xfs_info should show the updated data geometry. The numbers may differ slightly because tools use different units and reserve different metadata space, so compare the direction and approximate capacity rather than demanding identical figures.

6. Know the size options and common traps

• -d is the usual choice. The explicit -D size form takes a number of filesystem blocks, not a value such as 100G. Do not use it unless you have calculated the required block count from the filesystem geometry and have a specific reason to stop below the maximum.
• -m and -r/-R are specialised, not alternatives. -m changes the maximum inode allocation percentage; -r or -R resize a real-time section. Neither replaces ordinary data growth.
• -l/-L and -i are not implemented. The manual marks changing the log with -l or -L, and -i, as not implemented. Do not build a procedure around those switches. A real-time section is optional and does not need to have existed before an operation using the real-time options, but use that path only when the filesystem design requires it.