Context
A storage bill or partition redesign creates a request to make an XFS filesystem smaller. The supported XFS model allows growth, but the referenced Red Hat documentation does not provide a filesystem shrink utility. Reducing the underlying block device would remove addressable storage without safely relocating the filesystem's contents.
The practical task is a migration to a correctly sized destination. Prepare the source mount, application owner, data classification, downtime allowance and restore evidence. Obtain a consistent inventory before choosing a transfer method. The steps below prepare a reviewable plan; formatting a destination and switching production mounts require a tested change procedure.
Size and qualify the destination
- Verify the source with
findmnt -T /path/to/dataand inspect geometry withxfs_info /mountpoint. Comparedf -hwith a scopeddu -xinventory where its scanning cost is acceptable. Sparse files, hard links and filesystem metadata can make apparent file sizes differ from required destination allocation. Avoid treating one headline usage number as the complete sizing calculation. - Inventory the metadata the application depends on: numeric ownership, POSIX ACLs, extended attributes, hard links, sparse allocation and mandatory-access-control labels. Select a supported backup/restore or file-transfer approach that preserves these properties in this environment. A transfer command that copies filenames successfully may still omit information required after cutover.
- Define application consistency. Databases and other actively changing state need their own supported backup or quiescing method; copying open files does not automatically produce a recoverable dataset. Plan the final write pause, last synchronization and acceptance test. Record which jobs, uploads and background workers must stop writing, rather than naming only the front-end service.
- Rehearse on a non-production destination with the intended filesystem features and mount options. Confirm that the copied data fits with measured operational headroom. Include temporary files, growth and scheduled workload peaks. A smaller filesystem that fits only at the cutover instant is not a sustainable destination.
An illustrative undersized migration
In an illustrative document archive, the team sizes a destination from compressed export files but the application expands them during nightly indexing. The copy fits; the first index run does not. Rehearsing the operational workflow exposes the additional headroom requirement before the source storage is retired.
| Planning finding | Evidence needed | Implication |
|---|---|---|
| Source is XFS | Filesystem type and supported operations | Use migration rather than device reduction |
| Many sparse or linked files | Allocation and link-preservation checks | Transfer method affects destination size |
| Application writes during copy | Consistency and final-sync plan | Define a write pause |
| Copy fits, batch fails | Peak temporary-space use | Increase operational headroom |
Cut over with a reversible boundary
Preserve the source through the agreed acceptance period and avoid simultaneous writes to both copies. Use the planned mount or application-path switch and verify stable device identification. A rollback must account for data written after cutover; simply pointing back at an old copy can discard accepted business work.
Verify counts and integrity using application-appropriate checks, plus ownership, permissions and representative transactions. Check backups, restore paths and monitoring against the new mount. Test a planned reboot or equivalent persistence check in the rehearsal so the mount does not depend on an undocumented manual action.
Maintain the migration SOP
Record source and destination identities, transfer assumptions, final-write boundary, verification evidence and source-retirement criteria. Monitor free capacity and application growth after migration. Clouvenix Linux administration can help prepare storage transitions around recoverability and application consistency.
Technical reference
Red Hat filesystem capabilities and supported XFS growth operations.