We’re giving away 1,500 more DJI Tello drones. Enter to win ›
Roderick Smith | Published September 1, 2010
Simple partition resizing operations, such as those described in Part 1 of this series, Basics, usually conclude successfully. Sometimes, though, you need to do something different or troubleshoot problems. This article covers some of these situations. The first topic is LVM configuration and how it interacts with partition resizing. The second topic is troubleshooting techniques. Although a complete description of all the problems that can occur when resizing partitions might fill a book, a few basic principles can help you work through many common problems. Finally, this article describes some alternatives to partition resizing, should the problems you encounter prove insurmountable.
LVM is a disk allocation technique that supplements or replaces traditional partitions. In an LVM configuration, one or more partitions, or occasionally entire disks, are assigned as physical volumes in a volume group, which in turn is broken down into logical volumes. File systems are then created on logical volumes, which are treated much like partitions in a conventional configuration. This approach to disk allocation adds complexity, but the benefit is flexibility. An LVM configuration makes it possible to combine disk space from several small disks into one big logical volume. More important for the topic of partition resizing, logical volumes can be created, deleted, and resized much like files on a file system; you needn’t be concerned with partition start points, only with their absolute size.
Note: I don’t attempt to describe how to set up an LVM in this article. If you don’t already use an LVM configuration, you can convert your system to use one, but you should consult other documentation, such as the Linux LVM HOWTO (see Related topics), to learn how to do so.
If you’ve resized non-LVM partitions, as described in Part 1 of this series, and want to add the space to your LVM configuration, you have two choices:
Unfortunately, the GParted (also known as Gnome Partition Editor) tool described in Part 1 of this series does not support resizing LVM partitions. Therefore, the easiest way to add space to your volume group is to create a new partition in the free space and add it as a new physical volume to your existing volume group.
Although GParted can’t directly create an LVM partition, you can do so with one of the following tools:
If you use parted, you can use the set command to turn on the lvm flag, as in set 1 lvm on to flag partition 1 as an LVM partition. Using fdisk, you should use the t command to set the partition’s type code to 8e. You do the same with gdisk, except that its type code for LVM partitions is 8e00.
set 1 lvm on
In any of these cases, you must use the pvcreate command to set up the basic LVM data structures on the partition and then vgextend to add the partition to the volume group. For instance, to add /dev/sda1 to the existing MyGroup volume group, you type the following commands:
vgextend MyGroup /dev/sda1
With these changes finished, you should be able to extend the logical volumes in your volume group, as described shortly.
For file systems, resizing logical volumes can be simpler than resizing partitions because LVM obviates the need to set aside contiguous sets of numbered sectors in the form of partitions. Resizing the logical volume itself is accomplished by means of the lvresize command. This command takes a number of options (consult its man page for details), but the most important is -L, which takes a new size or a change in size, a change being denoted by a leading plus (+) or minus (-) sign. You must also offer a path to the logical volume. For instance, suppose you want to add 5 gibibytes (GiB) to the size of the usr logical volume in the MyGroup group. You could do so as follows:
lvresize -L +5G /dev/mapper/MyGroup-usr
This command adjusts the size of the specified logical volume. Keep in mind, however, that this change is much like a change to a partition alone. That is, the size of the file system contained in the logical volume is not altered. To adjust the file system, you must use a file system-specific tool, such as resize2fs, resizereiserfs, xfs_growfs, or the resize mount option when mounting Journaled File System (JFS). When used without size options, these tools all resize the file system to fill the new logical volume size, which is convenient when growing a logical volume.
If you want to shrink a logical volume, the task is a bit more complex. You must first resize the file system (using resize2fs or similar tools) and then shrink the logical volume to match the new size. Because of the potential for a damaging error should you accidentally set the logical volume size too small, I recommend first shrinking the file system to something significantly smaller than your target size, then resizing the logical volume to the correct new size, and then resizing the file system again to increase its size, relying on the auto-sizing feature to have the file system exactly fill the new logical volume size.
Remember also that, although you can shrink most Linux-native file systems, you can’t shrink XFS or JFS. If you need to shrink a logical volume containing one of these file systems, you may have to create a new smaller logical volume, copy the first one’s contents to the new volume, juggle your mount points, and then delete the original. If you lack sufficient free space to do this, you may be forced to use a backup as an intermediate step.
Although the text-mode tools just described get the job done, they can be intimidating. If you prefer to work with graphical user interface (GUI) tools, at least two are available for LVM operations:
Of the two, system-config-lvm provides a somewhat simpler and friendlier user interface; however, either will get the job done. Figure 1 shows system-config-lvm in action. To resize a logical volume, you click its name in the left panel, then click the Edit Properties button that appears in the middle panel. You can then use a slider to adjust the volume’s size.
Figure 1. GUI tools make resizing logical volumes relatively easy
Unfortunately, partition resizing operations sometimes don’t work as expected. Most commonly, the resizing software reports an error, frequently with a cryptic message. Although there are numerous possible causes of such problems, you can overcome a great many of them by applying a few simple workarounds, such as fixing file system problems and breaking a complex resizing operation down into several parts.
One common cause of resizing failures is a damaged file system. All production file systems include file system recovery tools that enable you to fix such problems, so running them on a file system prior to resizing it can often make for a smoother resizing operation.
In Linux, the file system check tool is called fsck, and you call it by passing it the device filename associated with the file system you want to check, as in fsck /dev/sda1 to check /dev/sda1. The fsck utility, however, is mainly a front-end to file system-specific tools, such as e2fsck (for ext2fs, ext3fs, and ext4fs). You can often gain access to more advanced options by calling the file system-specific tool directly. The -f option to e2fsck, for instance, forces it to check the device even if the file system appears to be clean. This option may be necessary to uncover corruption that’s not obvious in a cursory examination. Check the documentation for your file system-specific fsck helper program to learn about its options.
In most cases, it’s necessary to run fsck or its helper program on an unmounted file system. Thus, you may need to do this from an emergency boot disc, as described in Part 1 of this series.
If you run into problems with a non-Linux file system, you may be able to use fsck to check it; however, you may also need to boot into the file system’s native operating system to do the job properly. In particular, Microsoft® Windows® New Technology File System (NTFS) has only rudimentary maintenance tools in Linux. You must use the Windows CHKDSK utility to do a proper job of checking NTFS. You may need to run this utility several times, until it reports no more problems with the disk. The Linux ntfsfix utility performs what few checks are possible in Linux and then flags the file system for automatic checking the next time Windows boots.
Although not a file system integrity issue per se, disk fragmentation is another issue that might need attention. You can sometimes eliminate problems by performing a disk defragmenting operation prior to a resizing operation. This task is seldom necessary (and is usually not possible) with Linux native file systems; however, it may help with File Allocation Table (FAT) or NTFS partitions.
If you enter a number of resizing and moving operations into GParted and the operation fails, you can try entering just one operation at a time and then immediately clicking the Apply button. You might still run into problems, but you may at least be able to perform other operations that aren’t dependent on the one that causes problems. Depending on the details, you may be able to achieve at least some of your overall goals or find some other way to work around the problem.
In some cases, you may be able to split the resizing operation across multiple utilities. For instance, you may be able to use a Windows or Mac OS X utility to resize FAT, NTFS, or Hierarchical File System Plus (HFS+) partitions. Although GParted is the most user-friendly way to resize partitions in Linux, if just one operation is causing problems, using an underlying text-mode utility, such as resize2fs, may provide you with better diagnostic output or even succeed where GParted fails. Keep in mind, however, that most text-mode tools resize either partitions or file systems, but not both; you must combine both types of tools to resize a partition and its file system. The GNU Parted utility is an exception to this rule; like its GUI cousin, GParted, Parted resizes partitions and their contained file systems simultaneously.
Sometimes an attempt to resize your partitions just doesn’t work. Perhaps a file system has errors that can’t be easily resolved, or maybe you need to shrink a file system (such as XFS or JFS) that can’t be shrunk. In these cases, you must move on to an alternative, such as relocating directories in your existing partition structure, performing a backup-repartition-restore operation, or adding more disk space.
Sometimes you can relocate directories without actually repartitioning the disk. The trick is to use symbolic links to point from one location to another, even across partitions. For instance, suppose you’re using a Gentoo system, which can consume vast quantities of disk space in the /usr/portage and /var/tmp/portage directories. If you didn’t consider these needs when setting up your system, you might run out of space. You might, however, have space available on a separate /home partition. To use this space for Portage, you can create one or more directories in /home, copy the contents of /usr/portage or /var/tmp/portage to the new directories, delete the original directories, and create symbolic links in place of the originals that point to the new subdirectories of /home.
This approach can be effective and is convenient on a small scale; however, it does create a somewhat non-standard system, and it removes many of the advantages of using separate partitions. Thus, I recommend using this approach sparingly and preferably only on a short-term basis — for instance, as a stop-gap measure while you wait for a new hard disk to arrive or on a system you plan to retire in a month or two.
Prior to the development of file system resizing tools, the only practical way to repartition a disk was to back up its contents, repartition (creating new empty file systems), and restore the backup to the repartitioned disk. This approach continues to work, but of course it’s less convenient than using GParted to repartition nondestructively. On the other hand, for safety it’s best to create a backup before resizing partitions. So to be safe, you have to do half of this job anyway.
In today’s world, an external hard drive is often used as a backup medium. You can buy terabyte external disks for under $100, and after your partition juggling you can use them to back up your important files, to transfer large files between systems, or in other ways. Alternatively, you can use recordable DVDs, tape units, or network servers as backup systems.
Backup software can include old standbys such as tar or newer tools such as Clonezilla. Operational details vary depending on the software and the backup medium, so you should consult the backup software’s documentation for details.
If you need to modify your Linux boot partition or any partition that’s required for basic root (superuser) access, you need to perform these operations from an emergency boot system. Part 1 of this series described such systems.
Adding a disk can be a viable alternative to repartitioning, and in some cases, adding disk space may be preferable. Disk capacities continue to increase, and a newer disk is likely to be more reliable than one that’s several years old.
If you choose to replace an existing disk with a newer one, you should be able to transfer your existing system to the new disk with a tool such as Clonezilla or by using older tools, such as fdisk and tar. You may need to reinstall your boot loader, and, for this task, a boot using a tool such as the Super Grub Disk may be helpful. You can boot your system using this CD-based boot loader, then use grub-install or a similar tool to reinstall the GRand Unified Bootloader (GRUB) to your new hard disk.
If you buy a new disk to supplement, rather than replace, your existing disk, you need to decide what, if any, data to transfer to the new disk. You should partition the new disk using fdisk, GParted, or some other tool, transfer files to the new partitions, and then permanently mount the new disk’s partitions in your existing directory tree by editing /etc/fstab appropriately. Remember to delete any files you transfer to the new disk from the old disk. If you don’t, they’ll continue to consume disk space on the old disk, even if you mount the new disk to take over the original files’ directories.
However you do it, altering a working system’s disk allocation can be an anxiety-inducing task, and for good reason: Many things can go wrong. If such changes are necessary, though, you’ll find that your system is more usable after you make your changes. With a reduced risk of disk-full errors, you can get on with actually using your system for its intended task. The process of resizing your partitions can also help familiarize you with GParted and other disk utilities, as well as with the optimum sizes for various partitions. All of this can be useful knowledge the next time you install a new Linux system.
In this article, we have tried to assess the benefit of GPU offloading using OpenMP on memory and compute-intensive applications…
IBM Power SystemsLinux+
June 12, 2019
In case you have not seen, IBM and Red Hat have announced the intent to come together to be the…
Back to top