Author: Roderick W. Smith
This article is excerpted from the recently published book Linux Power Tools.
All too frequently, you discover only after installing Linux that your partitions aren’t the optimum size. For instance, you might have too much room in /usr and not enough room in /home. Traditional fixes for this problem include using symbolic links to store some directories that are nominally on one partition on another partition; and backing up, repartitioning, and restoring data. In many cases, a simpler approach is to use a dynamic partition resizer. Fortunately, partition resizers exist for the most popular Linux filesystems, as well, so you can use these tools to manage your Linux installation.
Dynamic partition resizers are inherently dangerous. In the event of a power outage, system crash, or bug, they can do serious damage to a partition. You should always back up the data on any partition you resize. Also, you should never run a dynamic partition resizer on a partition that’s currently mounted. If necessary, boot a Linux emergency system to resize your partitions.
Resizing ext2fs and ext3fs
Several tools exist to resize ext2 and ext3 filesystems:
resize2fs This program ships with the
e2fsprogs package included with most distributions. The
resize2fs program is fairly basic in terms of options. At a minimum, you pass it the device file associated with the partition, as in
resize2fs /dev/hda4. This command resizes the filesystem on /dev/hda4 to match the size of the partition. You can also pass the partition size in allocation blocks, as in resize2fs /dev/hda4 256000 to resize a filesystem to 256,000 blocks. The resize2fs program doesn’t resize partitions, just the filesystems they contain. Therefore, you must use resize2fs in conjunction with
fdisk to resize a partition and its filesystem. If you want to shrink a filesystem, you should do so first and then use
fdisk to shrink the partition to match. If you want to grow a partition, you use
fdisk first and then resize2fs. Because getting filesystem and partition sizes to match is tricky, it’s usually best to forgo resize2fs in favor of GNU Parted or PartitionMagic.
GNU Parted This program provides both filesystem and partition resizing at once, so it’s easier to use than
resize2fs. It’s described in more detail shortly, in “Using GNU Parted.”
PartitionMagic This commercial program from PowerQuest supports integrated filesystem and partition resizing operations of FAT, NTFS, ext2fs, ext3fs, and Linux swap partitions. PartitionMagic is easier to use than other ext2fs and ext3fs partition resizers, but it runs only from DOS or Windows. (The package ships with a DOS boot floppy image and a bootable CD ROM, so it’s still useable on a Linux-only system.)
Two tools are available for resizing ReiserFS:
resize_reiserfs This tool is ReiserFS’s equivalent of the
resize2fs program. Like
resize_reiserfs resizes the filesystem, but not the partition in which it resides, so you must use this tool in conjunction with
. If you only pass the program the partition identifier, it resizes the filesystem to fit the partition. If you pass an
-s option and filesystem size, the program resizes the partition to the requested size, which you can specify in bytes, kilobytes, megabytes, or gigabytes (the last three options require K, M, or G suffixes, respectively). Alternatively, you can specify a change to the partition size by prefixing the size with a minus (-) or plus (+) sign. For instance,
resize_reiserfs -s -500M /dev/sda5 reduces the size of the filesystem on /dev/sda5 by 500MB.
GNU Parted According to its web page, this program supports ReiserFS as well as other filesystems. Unfortunately, as of version 1.6.4, this support is more theoretical than real, because it relies on libraries that aren’t present on most distributions, and that even a fresh build can’t find when everything’s installed according to directions. With luck, though, this support will improve in the future.
The ReiserFS resizing tools are not as mature as are those for resizing ext2 and ext3 filesystems. In fact,
resize_reiserfs displays warnings about the software being beta.
XFS has long included a partition-resizing tool,
xfs_growfs. As the name implies, this program is designed for increasing a filesystem’s size, not decreasing it. Unlike most partition-resizing tools,
xfs_growfs is designed to work only on a mounted filesystem. The safest way to use it is to unmount the filesystem, delete the partition using
fdisk, create a new partition in its place, mount the filesystem, and then call
# xfs_growfs /mount/point
As you might guess, /mount/point is the partition’s mount point. You may also add the
-D size option to specify the filesystem size in allocation blocks. Various other options are also available, as described in the
xfs_growfs man page.
Although GNU Parted’s web page doesn’t mention XFS support, the source code does include an XFS subdirectory. Parted refuses to work on XFS partitions, but this may change in the future.
JFS includes a rather unusual partition-resizing ability: It’s built into the kernel’s JFS driver. You can use this feature to increase, but not to decrease, the size of the filesystem. As with most other partition-resizing tools, you must modify the partition size first by using fdisk to delete the partition and then recreate it with a larger size. After you’ve done this, you should mount the partition as you normally do and then issue the following command:
# mount -o remount,resize /mount/point
This command resizes the filesystem mounted at /mount/point to occupy all the available space in its partition. No other partition-resizing tools are available for JFS, although there is a JFS subdirectory in the GNU Parted source code, suggesting that Parted may support JFS in the future.
Using GNU Parted
Because Parted is the most sophisticated open source partition resizer, it deserves more attention. You can pass it a series of commands directly or use it in an interactive mode. The latter is more likely to be helpful for normal one-time uses. Passing commands to Parted enables you to write scripts to help automate partition resizing. Typically, you launch Parted in interactive mode by typing the program’s name followed by the device on which you want to operate. You can then type commands to resize, create, delete, and otherwise manipulate partitions:
# parted /dev/sda (parted) print Disk geometry for /dev/scsi/host0/bus0/target5/lun0/disc: 0.000-96.000 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 1 0.023 48.000 primary ext2 2 48.000 96.000 primary ext2 (parted) rm 2 (parted) resize 1 0.00 96.00 (parted) quit
This example deletes the second partition on the disk and resizes the first partition to fill all the available space. Unlike most Linux partition-management tools, Parted works in figures of megabytes. This fact can make translating Parted’s partition start and end points to and from the cylinder boundaries upon which
fdisk and other tools work tricky..
Most of the filesystem-resizing tools require that you modify the partition using
fdisk. (GNU Parted and PartitionMagic are exceptions to this rule.) Precisely how you modify the filesystem’s carrier partition depends on whether you’ll be shrinking or growing the partition. The simplest case is growing a partition. When doing this, you should follow these steps:
fdisk on the disk in question.
2. Type d in
fdisk to delete the partition you want to grow. You’ll be asked for the partition number.
3. Type n in
fdisk to create a new partition in place of the old one. You’ll be asked for the partition number and the start and end cylinders. The start cylinder must be the same as it was originally, and of course the end cylinder should be larger than the original.
4. Type w in
fdisk to write your changes to disk and exit.
5. Follow the procedure for your filesystem-resizing tool to increase the filesystem size.
Of course, in order to grow a partition, there must be free space on the disk into which to expand the partition. This normally means that you’ll have already deleted or shrunk a partition that follows the one you want to expand. If you want to expand a filesystem into space that’s before it on the disk, your job is much harder. It’s possible to expand the carrier partition as just described, but specifying an earlier starting point, and then use
dd to copy a filesystem from later in the new partition to earlier in the partition. This task is tricky, though, because you must compute precisely how far into the newly expanded partition the existing filesystem begins. An error can easily wipe out all your data. Thus, I don’t recommend attempting this task; instead, try creating a new filesystem in the earlier space and mount it at some convenient place in your directory tree. If the empty space is larger than the partition you want to move, you can create a new partition, move the original, verify that the copied partition is intact, delete the original partition, and expand the copied partition and the filesystem it contains.
In order to reduce the size of the filesystem, you must match the size of the partition to the filesystem, which can be a tricky task. Fortunately, there is a procedure that can make this task less error-prone:
1. Shrink the filesystem, using your filesystem-resizing tool, to a value that’s smaller than you intend. For instance, if you want to shrink a 700MB partition to 500MB, shrink it to 400MB.
fdisk to resize the partition to the target size, such as 500MB. This target size should be larger than the filesystem by a wide enough margin to be comfortable.
3. Use the partition-resizing tool to expand the filesystem into the extra space on the partition, filling it exactly.
As with increasing the size of the filesystem, the start point of the filesystem must remain untouched. When moving space between filesystems, this requirement can create an awkward situation: You can shrink an earlier partition, but expanding the next partition into the freed space is risky.
Defragmenting a disk
Microsoft filesystems, such as the File Allocation Table (FAT) filesystem and the New Technology File System (NTFS), suffer greatly from disk fragmentation — the tendency of files to be broken up into many noncontiguous segments. Disk fragmentation degrades performance because the OS may need to move the disk head more frequently and over greater distances to read a fragmented file than to read a nonfragmented file.
Fortunately, Linux’s native filesystems are all far more resistant to fragmentation than are Windows filesystems. Therefore, most Linux users don’t bother defragmenting their disks. In fact, defragmentation tools for Linux are hard to come by. One that does exist is called
defrag, but this package doesn’t ship with most distributions. Because it is an older tool, it won’t work with most modern ext2fs partitions, much less any of the journaling filesystems.
If you think your system may be suffering from fragmentation problems, you can at least discover how fragmented your ext2 or ext3 filesystems are by performing an
fsck on them. You may need to force a check by using the
-f parameter. This action will produce, among other things, a report on the fragmentation on the disk:
/dev/hda5: 45/8032 files (2.2% non-contiguous), 4170/32098 blocks
This report indicates that 2.2 percent of the files are noncontiguous (that is, fragmented). Such a small amount of fragmentation isn’t a problem. Unfortunately, the
fsck tools for other journaling filesystems don’t return this information, so you have no indicator of fragmentation on these filesystems. If you truly believe that fragmentation has become a problem, you may be able to improve matters by backing up the partition, creating a fresh filesystem, and then restoring the files. This procedure is likely to take far longer than the time saved in disk accesses over the next several months or years, though, so I only recommend doing it if you want to change filesystem types or have some other reason (such as replacing a hard disk) to engage in this activity.
As a general rule, fragmentation becomes a problem only if your disk is almost full. On a nearly full disk, Linux may have trouble locating a large enough block of free space to fit a file without fragmenting it. If you almost fill a disk and then delete files, the remaining files may or may not be fragmented, depending on which ones you deleted. For this reason, keeping your partitions from filling up is best. As a general rule, anything less than 80 to 90 percent full is fine from a fragmentation perspective.
Next time we’ll finish this series by looking at how to recover files, either ones that were deleted or ones that were lost as a result of filesystem corruption.