Guide to Non-Destructive Expansion of the Linux Root Directory

Introduction

In Linux server operations, it is common to encounter issues where the root directory (/) runs out of space due to insufficient initial partition planning. Directly formatting or rebuilding the partition can lead to the loss of system configurations and application data under the root directory. This article provides a complete non-destructive expansion process from disk partitioning to file system synchronization for the ext4 file system (with an adaptation plan for the XFS file system), allowing for expansion without unmounting the root directory, ensuring the original data is safely retained. This process is suitable for mainstream systems such as CentOS 7+/RHEL 7+/Ubuntu 18.04+.

1. Environment Preparation

1.1 Core Commands for Environment Confirmation

Execute lsblk to view the disk partition distribution, confirming the target disk (e.g., /dev/vda) total capacity and the size of the partition to be expanded (e.g., /dev/vda1, mounted at /); check the root directory file system type using df -T / (this article focuses on ext4, replace commands accordingly for XFS). The actual operation records are as follows:

1
2
3
4


# Check the root directory file system type and current capacity
[root@host-wingaso /home/wingaso]# df -T /
Filesystem     Type 1K-blocks     Used Available Use% Mounted on
/dev/vda1      ext4  20465232 19079708    320616  99% /

1.2 Essential Tools and Version Compatibility

• Core Tools: GNU Parted (version 3.5+; verify version compatibility with parted -v), resize2fs (version 1.46+; synchronized with the e2fsprogs toolset for ext4 file system expansion).
• Adaptation Scenarios: Supports Virtio block devices, SCSI, and other standard disk types; if using the XFS file system, replace the expansion tool with xfs_growfs and install the xfsprogs dependency package in advance.
• Key Reminder: Before operation, be sure to back up core data in the root directory (such as /etc system configuration directory, /home application data directory) using the rsync tool or disk snapshots to avoid data corruption due to interruptions during partition operations.

2. Partition Expansion: Expand Target Partition to Full Disk

2.0 Note: Parted Operation Risk Warning

The Parted tool has no built-in undo function, and all partition operations (such as resizepart to adjust size, rm to delete partitions) will take effect immediately upon execution and confirmation, and cannot be rolled back using Parted commands. Before proceeding, confirm the following:

1. Recheck the target partition number and starting position using parted /dev/vda print to avoid misoperation on other partitions;
2. Backup the current partition table information: execute parted /dev/vda print > /home/wingaso/partition_backup.txt to save the partition table details to local or remote storage for reference in case of misoperation;
3. If an error occurs during the operation, immediately stop further actions to avoid secondary damage to the partition structure.

2.1 Start the Parted Tool

Execute the command to enter Parted interactive mode, specifying the target disk to operate on (in this case, /dev/vda):

1
2
3
4
5


[root@host-wingaso /home/wingaso]# parted /dev/vda
GNU Parted 3.5
Using /dev/vda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted)

2.2 Confirm Basic Partition Information

Input print to view the partition table type (this article uses msdos, the logic for GPT partition tables is the same) and the starting position of the target partition (e.g., 1049kB, this parameter must be strictly preserved; modifying it may lead to data loss):

1
2
3
4
5
6
7
8
9


(parted) print                                                             
Model: Virtio Block Device (virtblk)
Disk /dev/vda: 107GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 
Number  Start   End     Size    Type     File system  Flags
 1      1049kB  21.5GB  21.5GB  primary  ext4         boot
(parted)

2.3 Execute Partition Expansion Operation

Input resizepart 1 (the number 1 is the partition number to be expanded, which must match the target partition number), when prompted with “Partition is in use”, input Yes to confirm continuation; when prompted with End?, input 100%, indicating that the partition should be expanded to occupy all available space on the disk (no manual calculation of remaining capacity is required):

1
2
3
4
5


(parted) resizepart 1                                                      
Warning: Partition /dev/vda1 is being used. Are you sure you want to continue?
Yes/No? Yes
End?  [21.5GB]? 100%                                                       
(parted)

2.4 Verify Partition Expansion Results

Re-execute the print command to confirm that the end position of the target partition has been updated to the total disk capacity (e.g., 107GB); input quit to exit the Parted tool. The system prompt “You may need to update /etc/fstab” can be ignored (no changes to the mount point require modification):

1
2
3
4
5
6
7
8
9
10
11


(parted) print
Model: Virtio Block Device (virtblk)
Disk /dev/vda: 107GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 
Number  Start   End    Size   Type     File system  Flags
 1      1049kB  107GB  107GB  primary  ext4         boot
(parted) quit                                                              
Information: You may need to update /etc/fstab.
[root@host-wingaso /home/wingaso]#

2.5 Core Function of Partition Expansion

Partition expansion only completes the “allocation of physical disk space”—by adjusting the boundary of the /dev/vda1 partition using the Parted tool, allowing it to occupy the entire 107GB space of the /dev/vda disk (originally only 21.5GB). However, at this point, the system still cannot use the newly added space because the file system’s “capacity recognition range” has not been updated. Executing df -lh will show that the root directory capacity is still around 20G.

2.6 Remedial Measures After Parted Misoperation

If partition damage or accidental deletion occurs after executing Parted operations, immediately stop all write operations to the target disk (to avoid data overwriting) and take targeted remedial actions based on the following scenarios:

1. Accidental adjustment of partition size (e.g., reducing partition):

• First, check the original starting/end positions of the target partition using the backup partition_backup.txt;
• Re-enter the Parted tool and execute resizepart 1 to restore the partition to its original size (strictly matching the backup starting/end parameters);
• Execute e2fsck -f /dev/vda1 to force repair the ext4 file system, and verify after repair using df -lh.

2. Accidental deletion of partition (no new data written):

• Install partition recovery tool testdisk (CentOS: yum install testdisk -y; Ubuntu: apt install testdisk -y);
• Run testdisk /dev/vda, follow the prompts to select “Analyse” to analyze the disk; the tool will automatically scan the historical partition table;
• After identifying the accidentally deleted partition, select “Write” to write the recovered partition table, and reboot the system to execute parted /dev/vda print to confirm recovery.

3. GPT Partition Table Misoperation:

• Use gdisk /dev/vda tool, input r to enter recovery mode, and execute o to scan for GPT partition items on the disk;
• After locating the target partition, input w to save the partition table, and execute partprobe /dev/vda to refresh kernel recognition.

Note: If new partitions have been created or data written to the disk after misoperation, the probability of original data being overwritten is very high, and the success rate of recovery significantly decreases. In this case, prioritize data recovery through backups.

3. File System Expansion: Synchronize Recognition of New Space

3.0 Relationship Between Partition Expansion and File System Expansion

Partition expansion is the “foundation for expansion”, while file system expansion is the “key to effectiveness”; both are indispensable. The former addresses the issue of “allocating disk space to partitions”, while the latter resolves the issue of “file systems recognizing and utilizing the newly added partition space”. Only by completing both operations can the root directory truly gain access to the full space after expansion.

3.1 Execute File System Expansion Command

For the ext4 file system, directly execute resize2fs /dev/vda1 (/dev/vda1 is the target partition path). This command supports online expansion (no need to unmount the root directory), and during execution, it will automatically complete file system checks and capacity adaptation, outputting “old_desc_blocks = X, new_desc_blocks = Y” indicating the expansion process, with the final prompt “file system block length updated” indicating completion:

1
2
3
4
5
6


[root@host-wingaso /home/wingaso]# resize2fs /dev/vda1
resize2fs 1.46.4 (18-Aug-2021)
Filesystem at /dev/vda1 is mounted on /; on-line resizing required
old_desc_blocks = 3, new_desc_blocks = 13
The filesystem on /dev/vda1 is now 26214144 (4k) blocks long.
[root@host-wingaso /home/wingaso]#

3.2 Core Function of File System Expansion

File system expansion allows the ext4 (or XFS) file system to “perceive and adapt” to the new capacity after partition expansion, updating the available space range of the file system to the actual size of the partition (107GB), while ensuring that the original data structure within the partition remains intact, allowing the system and applications to read and write the newly added space normally.

3.3 Version and Parameter Compatibility Notes

• If resize2fs prompts “file system corrupted”, first execute e2fsck -f /dev/vda1 to force check and repair (ensure the root directory is not unmounted; in extreme cases, enter single-user mode for operation);
• If using the XFS file system, replace the command with xfs_growfs /<code> (specifying the root directory mount point <code>/ instead of the partition path), and install the <code>xfsprogs<code> tool before execution: for CentOS, use <code>yum install xfsprogs -y<code>; for Ubuntu, use <code>apt install xfsprogs -y<code>.

4. Verification of Expansion Results

Execute df -lh to check the change in root directory capacity. If the output shows that the capacity of /dev/vda1 has been updated to the total disk capacity (e.g., 99G), and the usage rate has dropped from around 99% to about 20%, it indicates that the expansion was successful and the original root directory files are intact:

1
2
3
4
5
6
7
8
9


[root@host-wingaso /home/wingaso]# df -lh
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           7.7G     0  7.7G   0% /dev/shm
tmpfs           3.1G  600K  3.1G   1% /run
tmpfs           4.0M     0  4.0M   0% /sys/fs/cgroup
/dev/vda1        99G   19G   76G  20% /  # Capacity has been expanded to 99G, usage rate significantly decreased
tmpfs           7.7G  224K  7.7G   1% /tmp
[root@host-wingaso /home/wingaso]#

5. Core Issue Troubleshooting Process

5.1 Partition Expansion Failure

• Phenomenon: Parted prompts “partition is in use” or the partition size has not been updated after expansion;
• Troubleshooting: Execute fuser -m /dev/vda1 to check for occupying processes, and terminate abnormal processes using kill -9 [processID]; execute mount | grep /dev/vda to confirm if the disk is in read-only mode. If it is read-only, execute mount -o remount,rw /<code> to restore write access.

5.2 File System Expansion Failure

• Phenomenon: resize2fs prompts “file system corrupted” or “unable to expand online”;
• Troubleshooting: First execute e2fsck -f /dev/vda1 to force repair the file system; if it is an offline expansion scenario, enter rescue mode to unmount the root directory (umount /), then execute the expansion command.

5.3 Capacity Not Updated After Expansion

• Phenomenon: Both partition and file system indicate successful expansion, but the df command shows no change in root directory capacity;
• Troubleshooting: Execute mount -o remount / to remount the root directory; check if the file system type and tool match (to avoid using resize2fs on XFS partitions).

5.4 Recovery Failure After Parted Misoperation

• Phenomenon: Using testdisk/gdisk cannot recognize the original partition;
• Troubleshooting: Stop all write operations to the target disk and contact a professional data recovery team; if there is a complete data backup, directly restore from the backup to a new partition or disk.

6. Conclusion

The non-destructive expansion of the Linux root directory described in this article requires first expanding the partition using the Parted tool (which has no undo function) to allocate physical disk space, followed by using resize2fs (for ext4) or xfs_growfs (for XFS) to synchronize the file system expansion (allowing the system to recognize and use the newly added space), ensuring the safety of the original data. Misoperations can be attempted to recover using the corresponding tools.