VMware ESXi and vSphere Cluster Management

Adjust Linux File System Parameters with tune2fs and xfs_admin

Learn to safely inspect and modify ext2/ext3/ext4 and XFS metadata, check intervals, journals, reserved blocks, labels, UUIDs, and persistent mounts.

Linux file system administration begins by identifying two separate things: the block device and the file system stored on it. A block device is a storage device or partition accessed through a path such as /dev/sdc1. A file system is the on-disk format and data structures used to organize files and directories, such as ext4 or XFS.

This lesson covers tune2fs for ext2, ext3, and ext4 file systems, and xfs_admin for selected XFS metadata fields. Perform metadata changes carefully, normally while the target file system is unmounted.

Identify the Target Before Changing It

Never infer a target from a device name alone. Similar disks, partitions, logical volumes, and mount points can look alike. Confirm the device path, file system type, label, UUID, and mount point together.

lsblk -f
blkid /dev/sdc1
findmnt /dev/sdc1

lsblk -f gives a useful device-oriented summary. blkid reports identification metadata for a particular device. findmnt shows whether the device is mounted and where. A mount point such as /data is a directory, not a replacement for the device path.

Safety Requirements

Changing a label, UUID, journal, or maintenance setting modifies file system metadata. Before starting:

• Confirm the exact block device and file system type.
• Record the current label, UUID, mount point, and relevant maintenance values.
• Make or verify a usable backup, especially before journal conversion or identifier changes.
• Check whether the device is mounted.
• Stop processes using the file system and unmount it cleanly before offline administration.

findmnt /dev/sdc1
mount | grep '/dev/sdc1'
sudo umount /dev/sdc1

If unmounting reports that the target is busy, inspect processes, shells, services, containers, and working directories using the mount point. Do not force an unmount or metadata operation merely to bypass an unresolved usage problem.

Inspect ext Superblock Information

An ext superblock is core file system metadata describing attributes, layout, and maintenance state. The -l option lists the superblock fields without changing them.

sudo tune2fs -l /dev/sdc1

Important fields include:

• Filesystem volume name: the human-readable volume label.
• Filesystem UUID: the persistent unique identifier.
• Mount count: the number of mounts since a qualifying check.
• Maximum mount count: the mount-count threshold for requesting a check.
• Last checked: when the last qualifying check occurred.
• Check interval: the maximum elapsed time allowed between scheduled checks.
• Reserved block count and Reserved block percentage: capacity withheld for privileged use.

Key tune2fs Options

Control Periodic ext File System Checks

fsck is a file system consistency check and repair process. Periodic checks can detect and correct inconsistencies before they remain unnoticed, particularly after failures or unclean shutdowns.

Set a mount-count threshold with -c:

sudo tune2fs -c 30 /dev/sdc1
sudo tune2fs -l /dev/sdc1 | grep -E 'Mount count|Maximum mount count'

Set a time-based threshold with -i:

sudo tune2fs -i 8w /dev/sdc1
sudo tune2fs -i 90d /dev/sdc1
sudo tune2fs -i 3m /dev/sdc1

The suffixes mean d for days, w for weeks, and m for months. The mount-count and time-based limits can both apply: a check may be triggered when either applicable limit is reached. Select values according to the system role, storage reliability, downtime policy, and maintenance schedule. Setting a threshold to disable one mechanism is not automatically safer.

Manage an ext Journal

A journal is a log of file system changes used to improve recovery after an interruption or failure. It helps the system recover more predictably after an unclean shutdown, although it is not a replacement for backups.

tune2fs -j is the historical mechanism for adding a journal to an ext2 file system:

sudo tune2fs -j /dev/sdc1
sudo tune2fs -l /dev/sdc1

This is a significant file system change and results in ext3-compatible journaling behavior. Plan a maintenance window, back up the data, ensure the file system is unmounted, confirm compatibility with the operating system and recovery tools, and validate the resulting metadata. Do not use this command as a casual runtime adjustment.

Set ext Reserved Blocks

Reserved blocks are a percentage of ext capacity withheld for privileged use. They can allow root processes and system services to continue operating when ordinary users have filled the file system. On some workloads, the reserved area can also reduce fragmentation.

sudo tune2fs -m 5 /dev/sdc1
sudo tune2fs -l /dev/sdc1 | grep -E 'Reserved block count|Reserved block percentage'

A reserved percentage consumes capacity that ordinary users cannot normally use. A root or system partition often benefits from a meaningful reserve because logging and recovery must continue under pressure. A very large, noncritical data volume may use a smaller percentage when preserving usable capacity is more important. Base the value on workload and recovery requirements rather than copying a value blindly.

Set an ext Volume Label

A volume label is a human-readable identifier stored in file system metadata. Assign a meaningful and unique label:

sudo tune2fs -L data_volume /dev/sdc1
sudo tune2fs -l /dev/sdc1 | grep 'Filesystem volume name'
lsblk -f /dev/sdc1

Labels have file-system and tool-specific length and character constraints. Ext labels are commonly limited to 16 bytes, so use concise names and check the command result. A label used in persistent configuration must be unique enough to identify the intended file system.

Administer XFS Labels and UUIDs

XFS is a high-performance Linux file system. xfs_admin administers selected XFS metadata, including the label and UUID. It generally requires the target to be unmounted.

Key xfs_admin Options

Read an existing label, unmount the file system, make the change, and inspect the result:

sudo xfs_admin -l /dev/sdc1
sudo umount /dev/sdc1
sudo xfs_admin -L data_volume /dev/sdc1
sudo blkid /dev/sdc1
sudo mount /dev/sdc1 /data
findmnt /data

To change an XFS UUID:

sudo blkid /dev/sdc1
sudo umount /dev/sdc1
sudo xfs_admin -U generate /dev/sdc1
sudo blkid /dev/sdc1

Use other XFS utilities for operations outside the selected label and UUID administration supported by xfs_admin.

Update Persistent Mount Configuration

/etc/fstab commonly defines persistent mounts. Entries may identify a file system by UUID or label:

UUID=<current-uuid> /data xfs defaults 0 0
LABEL=data_volume /data ext4 defaults 0 2

After changing a label or UUID, search for the old value in /etc/fstab, boot-related configuration, scripts, container definitions, backup jobs, and monitoring rules. Replace stale references with the new identifier. A label change does not affect a UUID-based entry, but it does affect an entry using that label; the reverse is also true.

Test the edited configuration before rebooting:

sudo mount -a
findmnt /data

Review the command output and system logs for errors. A successful mount -a and a correct findmnt result provide stronger evidence than simply saving the configuration file.

Validate and Document Every Change

1. Reinspect the metadata after each operation.
2. Confirm the expected label, UUID, maintenance values, journal state, or reserved-space percentage.
3. Mount the file system at its intended mount point.
4. Confirm that the mount is accessible and has the expected file system type.
5. Review mount output and system logs for errors.
6. Record the old and resulting values, command used, date, operator, and any configuration updates.

Troubleshooting

The Target Is Mounted or Busy

Confirm the state with findmnt. Stop services, leave shells whose current directory is beneath the mount point, and stop other processes using it. Unmount cleanly before offline-only administration.

A Mount Fails After an Identifier Change

Obtain the current value with lsblk -f or blkid. Compare it with /etc/fstab and other dependent configuration. Correct spelling, identifier type, mount point, and file system type, then run mount -a and verify with findmnt before rebooting.

The Wrong Device Was Selected

Stop immediately. Map device, file system type, UUID, label, and mount point again using lsblk -f and findmnt. Use the documented pre-change values to restore required identifiers or configuration, and investigate any resulting storage or file system condition before proceeding.

Checks Occur More Often Than Expected

Inspect the current values with tune2fs -l. Either the mount-count threshold or the elapsed-time threshold may have been reached. Adjust -c or -i only after reviewing the maintenance policy. Do not disable integrity checks without an alternative plan.

A Force Option Seems Necessary

tune2fs -f can force an operation past certain warnings or error conditions. First validate the device, file system type, mount state, arguments, and storage health. A force option is not a substitute for diagnosing an invalid target, a mounted file system, or underlying storage problems.

xfs_admin Does Not Work as Expected

Confirm that the target is XFS, unmount it, and check that the requested operation is supported by the selected xfs_admin option. Use the appropriate XFS inspection or repair utility for other tasks.

Safe Change Workflow

1. Identify: map the block device to its file system type, UUID, label, and mount point.
2. Record: save current metadata and dependent configuration.
3. Protect: verify backups and plan a maintenance window.
4. Unmount: stop users and services, then unmount cleanly.
5. Modify: run the appropriate tune2fs or xfs_admin command.
6. Verify: inspect metadata immediately after the operation.
7. Update: correct /etc/fstab and other references if an identifier changed.
8. Test: mount the file system, run mount -a where appropriate, and confirm the intended mount point.
9. Document: record prior and resulting values and the validation results.