Softpanorama

Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells

Resizing LVM logical partition

News

Linux Disk Management

Recommended Books

Recommended Links

HOW-TOs

Recommended Papers

Reference

Repartitioning
Snapshots Operations on Logical Volumes LVM Tools Software RAID Ext3 filesystem Loopback filesystem Grub Recovery
Basic LVM commands Create a new volume Get information about free space Create and mount a partition Extend the partition Resize the file system> Recover LVM volumes Moving a volume group to another system
Linux Troubleshooting modprobe FATAL could not load modules.dep Controlling LVM Device Scans with Filters Humor Etc

How to extend and resize an LVM partition on the fly

A file system on logical volume may be extended. Also more space may be added to a VG by adding new partitions or devices with the command: vgextend. For example:

lvextend -L +80G /dev/mapper/vg00-sge
  Extending logical volume sge to 90.00 GB
  Logical volume sge successfully resized 

Here is a typical df map of a server with volume manager installed. As you can see all partitions except /boot partition are referred vi path /dev/mapper/VolGroup00-LogVolxx where xx is two digit number:

# df -l
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/cciss/c0d0p3     31738420   4497848  25602344  15% /
/dev/mapper/vg00-var  15870920    351348  14700372   3% /var
/dev/cciss/c0d0p2     99188500   3149924  90918664   4% /home
/dev/mapper/vg00-tmp   7935392    320524   7205268   5% /tmp
/dev/cciss/c0d0p1       497829     31672    440455   7% /boot
tmpfs                  3051112         0   3051112   0% /dev/shm
/dev/mapper/vg00-sge  10321208   8225504   1571416  84% /sge

After extending the volume group and the logical volume, it is possible to resize the file system on the fly. This is done using resize2fs. Let's get a DF map of the server first:

# df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/cciss/c0d0p3     31738420   4497848  25602344  15% /
/dev/mapper/vg00-var  15870920    351364  14700356   3% /var
/dev/cciss/c0d0p2     99188500   3149924  90918664   4% /home
/dev/mapper/vg00-tmp   7935392    320524   7205268   5% /tmp
/dev/cciss/c0d0p1       497829     31672    440455   7% /boot
tmpfs                  3051112         0   3051112   0% /dev/shm
/dev/mapper/vg00-sge  10321208   7272668   2524252  75% /sge
Now we can perform resizing (it's better first to backup data just in case, but this step is omitted for brevity):
# resize2fs /dev/mapper/vg00-sge
resize2fs 1.39 (29-May-2006)
Filesystem at /dev/mapper/vg00-sge is mounted on /sge; on-line resizing required
Performing an on-line resize of /dev/mapper/vg00-sge to 23592960 (4k) blocks.
The filesystem on /dev/mapper/vg00-sge is now 23592960 blocks long. 

Now let's check results via DF map:

#df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/cciss/c0d0p3     31738420   4497848  25602344  15% /
/dev/mapper/vg00-var  15870920    351368  14700352   3% /var
/dev/cciss/c0d0p2     99188500   3149924  90918664   4% /home
/dev/mapper/vg00-tmp   7935392    320524   7205268   5% /tmp
/dev/cciss/c0d0p1       497829     31672    440455   7% /boot
tmpfs                  3051112         0   3051112   0% /dev/shm
/dev/mapper/vg00-sge  92891128   7285756  80887804   9% /sge 

Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Mar 18, 2014] Resizing Linux partitions, Part 2 Advanced resizing

Resizing LVMs

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 Resources), to learn how to do so.

Resizing physical volumes

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:

  • You can create a new partition in the empty space and add the new partition to your LVM.
  • You can resize an existing LVM partition, if it's contiguous with the new space.

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:

  • parted (text-mode GNU Parted)
  • fdisk for Master Boot Record (MBR) disks
  • gdisk for globally unique identifier (GUID) Partition Table (GPT) disks

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.

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:

pvcreate /dev/sda1
vgextend MyGroup /dev/sda1

With these changes finished, you should be able to extend the logical volumes in your volume group, as described shortly.

Resizing logical volumes

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.

[Jul 23, 2012] Extend LVM partition

To extend a LVM partition for Eg. say /usr

follow the below given steps

boot the system using a live cd

umount/mnt/lvm/localvg-usrlv
lvextend --size +2G -n /dev/localvg/usrlv
e2fsck -f /dev/localvg/usrlv
resize2fs /dev/localvg/usrlv
e2fsck -f /dev/localvg/usrlv

sem007

Hi rconan,

If your volume gorup has free space then simply you can run lvextend.

if your volume-gorup has no space and you have free space on you HDD then you can follow steps suggested by cmisip.

http://www.howtoforge.com/logical-vo...a-volume-group

A link provide how to extend VG. after that you can extend LV.

HTH

[Sep 14, 2010] Resizing Linux partitions, Part 2 Advanced resizing by Roderick W. Smith

Simple partition resizing operations, such as those described in Part 1 of this series, 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.

Resizing LVMs

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 Resources), to learn how to do so.

Resizing physical volumes

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.

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:

pvcreate /dev/sda1
vgextend MyGroup /dev/sda1
With these changes finished, you should be able to extend the logical volumes in your volume group, as described shortly.

Resizing logical volumes

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.

Using GUI LVM tools

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.

Troubleshooting problems

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.

Fixing file system problems

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.

Breaking the operation into parts

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.

Going to plan B

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.

Relocating directories without repartitioning

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.

Backing up, repartitioning, and restoring

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 disk space

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 newsk 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.

Summary

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.

Tips and tricks What is the procedure to resize an LVM2 logical volume and the ext2 or ext3 filesystem

Outdated...
Red Hat Magazine

It is recommended that a resizing procedure be tested before performing it on a filesystem that contains critical data. It is also strongly recommended that data backups are created and verified before resizing filesystems. To assist the reader in becoming familiar with the resizing procedure, the rest of this article describes a scenario in which un-partitioned disk space is used to test logical volume and ext3 filesystem resizing.

In this test procedure, first we create a new partition (/dev/hda2) using un-partitioned disk space. A new volume group (TestVG) and logical volume (TestLV) are then created using a physical volume created on the partition. An ext3 filesystem is then created on the logical volume, it is checked, and then mounted. A new physical volume (/dev/hda3) using the rest of the un-partioned disk space is then created and added to the volume group and logical volume. Finally, the filesystem on the logical volume is resized, and the integrity of the filesystem is checked.

In this test procedure, the parted, lvm, mount, mkfs.ext3, df, e2fsck and ext2online programs are used. The reader is encouraged to become familiar with these programs by consulting the manual pages.

[Aug 11, 2007] Logical volume management by Klaus Heinrich Kiwi

Sep 11, 2007 | IBM developerworks
Volume management is not new in the -ix world (UNIX®, AIX, and so forth). And logical volume management (LVM) has been around since Linux® kernel 2.4v1 and 2.6.9v2. This article reveals the most useful features of LVM2-a relatively new userspace toolset that provides logical volume management facilities-and suggests several ways to simplify your system administration tasks.

Manage volumes

To manage volumes, you need to know how to reduce LVs and how to remove PVs.

Reducing logical volumes
You can reduce an LV in the same way you extend one, using the lvreduce command. From the LVM side, this operation can always be done with the volume online. One caveat: the majority of filesystems don't support online filesystem shrinking. Listing 10 demonstrates a sample procedure:


Listing 10. Reducing an LV
#unmount LV
umount /path/to/mounted-volume
#shrink filesystem to 4G
resize_reiserfs -s 4G /dev/test-volume/data
#reduce LV
lvreduce -L 4G /dev/vg00/test

Be careful with sizes and units: the filesystem should not be longer than the LV!

Removing physical volumes
Imagine the following situation: You have a volume group with two 80GB disks, and you want to upgrade those to 160GB disks. With LVM, you can remove a PV from a VG in the same way they are added (that means online!). Notice, though, that you can't remove PVs that are being used in an LV. For those situations, there is a great utility called pvmove that can free PVs online so you can replace them easily. In a hot-swap environment, you can even swap all disks with no downtime at all!

pvmove's only requirement is a contiguous number of free extents in the VG equivalent to the number of extents to be moved out of a PV. There's no easy way to directly determine the largest free set of contiguous PEs, but you can use pvdisplay -m to display the PV allocation map:


Listing 11. Displaying the PV allocation map
                
#shows the allocation map
pvdisplay -m
  --- Physical volume ---
  PV Name               /dev/hda6
  VG Name               test-volume
  PV Size               4.91 GB / not usable 1.34 MB
  Allocatable           yes (but full)
  PE Size (KByte)       4096
  Total PE              1200
  Free PE               0
  Allocated PE          1200
  PV UUID               BA99ay-tOcn-Atmd-LTCZ-2KQr-b4Z0-CJ0FjO

  --- Physical Segments ---
  Physical extent 0 to 2367:
    Logical volume      /dev/test-volume/data
    Logical extents     5692 to 8059
  Physical extent 2368 to 2499:
    Logical volume      /dev/test-volume/data
    Logical extents     5560 to 5691

  --- Physical volume ---
  PV Name               /dev/hda7
  VG Name               test-volume
  PV Size               9.77 GB / not usable 1.37 MB
  Allocatable           yes
  PE Size (KByte)       4096
  Total PE              2500
  Free PE               1220
  Allocated PE          1280
  PV UUID               Es9jwb-IjiL-jtd5-TgBx-XSxK-Xshj-Wxnjni

  --- Physical Segments ---
  Physical extent 0 to 1279:
    Logical volume      /dev/test-volume/LV0
    Logical extents     0 to 1279
  Physical extent 1280 to 2499:
    FREE

In Listing 11, note that there are 2,499-1,280 = 1,219 free contiguous extents available, meaning that we can move up to 1,219 extents from another PV to /dev/hda7.

If you want to free a PV for replacement purposes, it's a good idea to disable its allocation so that you can be sure it remains free until you remove it from the volume group. Issue this before moving out the data:


Listing 12. Before freeing, disable a PV's allocation
                
#Disable /dev/hda6 allocation
pvchange -xn /dev/hda6

Once free, see that the PV /dev/hda6 is 1,200 extents large and there are no free extents. To move the data from this PV, issue the following:


Listing 13. Moving data from the freed PV
                
#Move allocated extents out of /dev/hda6
pvmove -i 10 /dev/hda6

The -i 10 parameter in Listing 13 tells pvmove to report back status once every 10 seconds. Depending on how large the data to be moved is, this operation can take several minutes (or hours). This can also be done in the background with the -b parameter. In this case, status would be reported to the syslog.

In case you just don't have enough free contiguous extents to use in a pvmove operation, remember that you can always add one or more disks/partitions to a VG, thus adding a contiguous space, free for pvmove use.

Other useful LVM operations
Consult the man pages for more details on these other useful LVM operations:

Extend volumes

This is the easy part. If you have enough free space in the volume group, you just have to use lvextend in order to extend the volume. There's no need to unmount it. Afterwards, also extend the filesystem inside the logical volume (they are two separate things, remember). Depending on the filesystem you're using, it also can be extended online (that's it, while mounted!).

If you don't have enough space in your VG, you'll need to add additional physical disks first. To do that:

You can also create or add several physical disks at once with:

pvcreate /dev/hda2 /dev/hda3 /dev/hda5 
vgextend test-volume /dev/hda2 /dev/hda3 /dev/hda5

Once you're ready with adding PVs and have sufficient space to grow your logical volume, use lvextend to extend the logical volume(s): lvextend -L 8G /dev/test-volume/data. This command extends the /dev/test-volume/data LV to the size of 8GB.

There are several useful parameters for lvextend:

Take a look at lvextend(8) for more details.

After extending the LV, don't forget to also extend the filesystem (so you can actually use the extra space). This can be done online (with the filesystem mounted), depending on the filesystem.

Linux LVM Resizing partitions

This post is designed as a blind test, meaning its sole purpose is for testing and learning LVM functionality. In this process we will work with an existing LVM that contains live data to grow, shrink and move it's contents around. Before we do anything, a disclaimer is in order:

DISCLAIMER: Aside from the disclaimer already present on the site at the bottom, I do not recommend you to follow these instructions. The exception exists where you wish to learn and test functionality on non PRODUCTION environments (ie meaning DEVELOPMENT or QUALITY ACCEPTANCE testing environments). Using these steps puts you at risk of loosing your data. BACKUP YOUR DATA BEFORE PROCEEDING. By reading the below and following any steps, you are agreeing to undertake any and all risks associated with the resulting consequences of following the steps on this site and post below.

Having said that, let's begin. First, we'll begin by getting some information and marking our LVM for change. The goal here is to eventually resize this partition that spans the entire 1.5TB to something much smaller (around 200GB) that we can copy to a smaller part of the hard drive to free space for a new installation and VG. NOTE: Only one hard drive will be used here to do this with:

Before we begin, please note the version of LVM we are using here:

LVM version: 2.02.83(2)-RHEL6 (2011-03-18)
Library version: 1.02.62-RHEL6 (2011-03-18)
Driver version: 4.20.6

The main goal, is to resize and shape our LVM to make room for another installation. The images below illustrate the goals for this post. The final image represents the setup, including a resized copy (backup) of the original VG VolGroup called VG VGEntertain sitting on /dev/sda3 at the end of the partition:

LVM resizing.jpg

If your version differs, these steps may not work the same way for you. The steps:

  1. fdisk -l (Just root partitions should be listed)
  2. lvm vgchange -a y
  3. fdisk -l (You should see the volume groups listed now.)
  4. Run ll /dev/VolGroup/ to locate and identify your partitions. Note the one you want to resize based on the fdisk and ll output above.
  5. To check the partition, you may want to mount it first using these steps:
    su
    lvm vgchange -a y
    lvm lvdisplay
    mkdir /mnt/root
    mount /dev/VolGroup/lv_root /mnt/root

    This is good for any data recovery etc.

  6. In this case I used it to verify that this is an ext4 partition from the /mnt/root/etc/fstab file.
  7. After verifying the usage on the partition from last boot to it, I ran

    resize2fs -p /dev/VolGroup/lv_root 32G

    from 500GB. This partition was only 3% full anyway and I needed the extra space. This step may take a while.

  8. Next type:

    lvm lvresize /dev/VolGroup/lv_root –size 32G

    This step should be quick but will give you a warning message before you resize.

  9. Run and record the output of lvm pvs and lvm lvs. I booted with PXE so could scp the files to the server using scp lvm.pvs.lvs.txt 192.168.0.1:/home/Files/HTPC or equivalent for you.
  10. At this point we need to manually 'defragment' by moving the other partitions next to each other in the volume group. We'll start with the swap. We'll delete it then recreate it.
  11. I'll recreate the swap in this manner to move it to the beginning right next to the root partition:
    lvm lvremove /dev/VolGroup/lv_swap
    lvm lvcreate –size 4G –name lv_swap VolGroup
    mkswap /dev/VolGroup/lv_swap

  12. There is another volume in my volume group LogVol02 where /home resides. I've got some files in there. It's 1TB and has about 100G of files on it. I'll extend this volume then shrink it down to a smaller size which should line it up with the above resized volumes. The steps are in reverse, somewhat, of the shrinking steps:
    lvm lvextend -L+500G /dev/VolGroup/LogVol02

  13. This however, gave me an error saying I don't have that much space to extend by. So I have to use a smaller number.
    Insufficient free space: 128000 extents needed, but only 116792 available.
  14. This message is telling us exactly how much we can extend it with:
    500G/128000 * 116792=456.21875=NewSize
  15. I rerun the command like this:
    lvm lvextend -L+456218M /dev/VolGroup/LogVol02

    Rounding up size to full physical extent 445.53GiB
    Extending logical volume LogVol02 to 1.32 TiB
    Logical volume LogVol02 successfully resized

  16. Now we need to extend the filesystem in this LV (You can get the actual size of this volume from fdisk -l):

    resize2fs -p /dev/VolGroup/LogVol02 1450G

    But I got:

    The containing partition (or device) is only 353992704 (4k) blocks.
    You requested a new size of 380108800 blocks.

    Doing the math 353992704 * 4096 = 1449.95. Dividing this 3 times by 1024 yields 1350.375G (or 1382784M). I'll use M instead with this number. But it wanted me to run e2fsck on it first.

  17. Resized the LV using:

    resize2fs -p /dev/VolGroup/LogVol02 1382784M

    This step is fairly quick but the next one isn't.

  18. Now resize the file system back down before we also resize the LV down to 500G. (I have about 115GB of storage there anyway. This should give us about 1TB to work with):

    resize2fs -p /dev/VolGroup/LogVol02 500G

    This may take a while.

  19. Next resize the LV to 500G:

    lvm lvresize /dev/VolGroup/LogVol02 –size 500G

    Now all your volumes should be resized and lined up. We should be able to resize the VG down to 538G now. You can mount the /dev/VolGroup/LogVol02 on /mnt/mr or another folder of your choosing then issuing df -h to check the size.

  20. Now I run:

    lvm pvresize /dev/sda2 –setphysicalvolumesize 500G (Really should be 538G)

    This tells me:

    /dev/sda2: cannot resize to 127999 extents as 137216 are allocated.
    0 physical volmes(s) resized / 1 physical volume(s) not resized

    This calculated for me the numbers that I will need. However, I still couldn't extend even with sizes of 700G which told me that my attempt to grow then shrink didn't work as planned. My LogVol02 was now sitting in between two free areas only only shrunk around it's center so to speak.

  21. We can see the above locations by issuing:

    lvm pvdisplay –maps

    which shows:

    – Physical Segments –
    Physical extent 0 to 8191
    Logical volume /dev/VolGroup/lv_root
    Logical extents 0 to 8191

    Physical extent 8192 to 9215
    Logical volume /dev/VolGroup/lv_swap
    Logical extents 0 to 1023

    Physical extent 9216 to 126007
    FREE

    Physical extent 126008 to 254007:
    Logical volume /dev/VolGroup/LogVol02
    Logical extents 0 to 127999

    Physical extent 254008 to 357648:
    FREE

    So my outermost extent is 254008.

  22. So what I'll do is shrink the LogVol02 down to a smaller size (Mounting and checking with df -h showed only 119G usage on it) instead of 500G so it is easier to move, shrink the PV to what ever the last used extent was, create another PV group in the now free space on the disk, move the LogVol02 LV to the new PV, remove the old PV and recreate it, then move the old LV back and remove the new PV created earlier in this step. All this should line things up. So here we go:

    resize2fs -p /dev/VolGroup/LogVol02 150G (fsck if it asks you too)
    lvm lvresize /dev/VolGroup/LogVol02 –size 150G

    Check usage and space (Was at 85% after above): mount /dev/VolGroup/LogVol02 /mnt/mr; cd mr; df -h;
    lvm pvdisplay –maps
    (Last FREE starts at 164408 instead of 254008, which is good) LV LogVol2 is now 0 to 38399 extents.
    lvm pvresize /dev/sda2 –setphysicalvolumesize 643G ( 150G / 38399 * 164407. Complained about 642G ) Don't care about precision here. Just need to shrink to make room for a new VG. Only 164408 to 164606 is left at the end. This is tiny in comparison.

    The next step here was to create a new VG on the same PV:

    lvm vgcreate BackupVG /dev/sda2

    But that gave me:

    Physical volume '/dev/sda2' is already in volume group 'VolGroup'
    Unable to add physical volume '/dev/sda2' to volume group 'BackupVG'

    This was odd but could not find anything conclusive until I read this:

    "PVs and LVs cannot be shared between or span different VGs" - http://en.wikipedia.org/wiki/Logical_volume_management

    This basically says I can't have two VG's on the same PV in this case, on the the same /dev/sda2. So I have to resize the partition, then create a new partition on the free space, then a VG on that then move the LV to the VG on the new PV. (This is certainly turning into an exercise)

    Now we determine the new end sector for our partition. Well need to verify numbers and calculate it:

    lvm pvs –units g ( VolGroup PSize / PFree is 643.00g / 457.00g )
    lvm pvs –units s ( VolGroup PSize / PFree is 1348460544S / 958390272S )
    parted /dev/sda unit s print ( Start / End / Size for the lvm listead as 409663s / 2930272064s / 2929862402s. It is of type Primary and the flags are lvm)

    Because the VG is a whole unit, not fragmented, it's start to end should be exactly the sectors highlighted in green. So the next end sector should be the green and blue number (1348870207+2042(safety margin) = 1348872249 ). There is the extra free space in the middle we are trying to get rid of but that is included in the total VG size, which is good. If we really need that 1MB later, we can extend it.

    WARNING: These steps will remove /dev/sda2 partition on sda and recreate it. If you did not get the end sector correct, this can truncate your partition resulting in DATA LOSS. There is NO backing out from this. Make sure you made a backup of your partitions earlier.

    parted /dev/sda rm 2
    parted /dev/sda mkpart primary 409663s 1348872249s
    parted /dev/sda set 2 lvm on
    parted /dev/sda print
    fdisk -l /dev/sda

    Done. Now check with parted /dev/sda unit s print and the end size should match exactly the number you specified above when recreating it.

    At this point check the FS using e2fsck -f /dev/VolGroup/LogVol02 to ensure things are still fine.

    Now I'm at the point where I have /dev/sda1 and /dev/sda2 and have about 500GB of free space to create another partition /dev/sda3.

    At this point I'll boot up into the system to ensure things still can be booted up as well. This is the ultimate test. I'll return to the PXE boot on the second reboot. The system booted up fine.

    Now we need to make another partition and VG to where we will move LogVol02. To do this, create a new partition /dev/sda3 then create the VG on that.

    parted /dev/sda "mkpart primary ext4 1348462588s -1s" (Need the " because shell tries to interpret the – )
    parted /dev/sda set 3 lvm on
    lvm vgcreate BVolGroup /dev/sda3 (But this failed as I had to reboot after creating the above partitions before making VG's)
    lvm pvcreate /dev/sda3
    lvm vgcreate BVolGroup /dev/sda3 (This would create the PV but since we're doing this manually…..)

    Now we should be able to move the LV from /dev/sda2. The way we do this is not with LVM but rsync (or dd). dd should be quicker but can leave empty unusable space that could cause more work. This is because we cannot move LV's between VG's according to LVM rules. We could move LV's to other PV's within the same VG (A VG can span multiple PV's) but that is not our setup here.

    Unfortunately, it occurred to me that since we can't move LV's between VG's, and I have more then 400G space in the middle of my VolGroup, I should be able to create a new LV, rsync between them, then rename the new one. This should do the trick:

    lvm lvcreate –name /dev/VolGroup/LogVol01 –size 150G
    lvm pvdisplay –maps
    (verify the volumes LogVol01 and LogVol02 are identical in extents)
    mke2fs -t ext4 /dev/VolGroup/LogVol01
    mkdir /mt/amr /mnt/bmr
    mount /dev/VolGroup/LogVol02 /mnt/amr

    mount /dev/VolGroup/LogVol01 /mnt/bmr
    cd bmr
    rsync -avh /mnt/amr/* /mnt/bmr

    Since the copy procedure target and source are using the same physical disk, the write/read speeds will be halved.

    umount /mnt/amr; umount /mnt/bmr
    lvm lvremove /dev/VolGroup/LogVol02
    lvm lvrename /dev/VolGroup/LogVol01 /dev/VolGroup/LogVol02

    Let's see how everything looks like now before we resize the VG / PV:

    lvm pvdisplay –maps
    lvm pvs –units g
    ( VolGroup PSize / PFree is 643.00g / 457.00g )
    lvm pvs –units s ( VolGroup PSize / PFree is 1348460544S / 958390272S )
    parted /dev/sda unit s print ( Start / End / Size for the lvm on /dev/sda2 listead as 409663s / 1348872249s / 1348462587s. It is of type Primary and the flags are lvm)

    Finally, our LV's show to be lined up in the VG, with the free space showing up between extents 47616 and 164606. We now need to resize the VG / PV as we did earlier above, but to a now smaller size. So again, here are the calculations:

    lvm pvresize /dev/sda2 –setphysicalvolumesize 187G (150G / 38399 * 47616 = 186. It complained about 186 as there is a fractional remainder)

    Check again with:

    lvm pvs –units s ( VolGroup PSize / PFree is 392159232S / 2088906S )
    parted /dev/sda unit s print ( Start / End / Size for the lvm on /dev/sda2 listead as 409663s / 1348872249s / 1348462587s. It is of type Primary and the flags are lvm)

    Now we can shrink our /dev/sda2 partition to it's minimal size (409663s + 392159232S + 2048(safety margin)):

    parted /dev/sda rm 2
    parted /dev/sda mkpart primary 409663s 392570943s
    parted /dev/sda set 2 lvm on
    parted /dev/sda print
    fdisk -l /dev/sda

    Remove the backup volume we created earlier:

    lvm vgremove /dev/BVolGroup
    lvm pvremove /dev/sda3

    And let's test with a restart. After the reboot, we'll move the entire PV / VG to partition /dev/sda3 in preperation for installing Scientific Linux (Another RHEL 6.1 clone like CentOS but with OpenAFS and Kerberos pre included).

    lvm lvresize /dev/VolGroup/LogVol02 -l+255 (to resize to the maximum VG size as only 255 extents were left available at the end.)
    lvm pvsize –maps (Should now show no free extents.)

    There should now be ample 1.5TB – 187GB of free space on the physical device /dev/sda3. We'll now proceed to move everything to /dev/sda3 in the next step.

    This is how things look now visually:

  23. Now we'll create /dev/sda3 at the end of the disk with the exact same size as /dev/sda2. Then we'll pvmove from 2 to 3:

    parted /dev/sda unit s print free
    parted /dev/sda mkpart primary 2538115887s 2930277167s
    (Based on results of above command and START +1 for an exact size of 392161281s as /dev/sda2)
    parted /dev/sda set 3 lvm on
    parted /dev/sda unit s print free
    lvm pvs

  24. Now we create the PV:

    lvm pvcreate /dev/sda3

    You will notice that after we create the above PV, it's size may be greater then the actual size reported by parted:

    Before:
    PV VG Fmt Attr PSize PFree
    /dev/sda2 VolGroup lvm2 a- 187.00g 0

    After:
    PV VG Fmt Attr PSize PFree
    /dev/sda2 VolGroup lvm2 a- 187.00g 0
    /dev/sda3 lvm2 a- 754.07g 754.07g

  25. Notice the large PSize of 754.07g that doesn't match the 392161281s sector size of /dev/sda3 (Which should be equal to /dev/sda2). This is why we need to resize the PV to it's actual size before we extend anything:

    pvresize –test -v –setphysicalvolumesize 392161281s /dev/sda3
    pvresize -v –setphysicalvolumesize 392161281s /dev/sda3 (If everything is ok from the above step.)

    PV VG Fmt Attr PSize PFree
    /dev/sda2 VolGroup lvm2 a- 187.00g 0
    /dev/sda3 lvm2 a- 187.00g 187.07g

    (Double check with lvm pvs –units s and resize again if necessary to match /dev/sda2.)

  26. Now we should be ready to extend the VG:

    lvm vgextend VolGroup /dev/sda3

  27. Finally, we do a pvmove from 2 to 3. Before you do, ensure that after the vgextend, both /dev/sda2 and /dev/sda3 print the same size by using lvm pvs –units s:

    lvm pvmove /dev/sda2 /dev/sda3
    lvm pvs -o +tags
    (To check the PV's in the VG VolGroup)

    The above will take some time since /dev/sda2 is around 187GB in this case:

  28. Once the move is complete and without errors, reduce the VG by /dev/sda2:

    lvm vgreduce VolGroup /dev/sda2

    Mount and check manually. lvm vgdisplay should also show half the space again.

  29. Now remove /dev/sda2 PV:

    lvm pvremove /dev/sda2

  30. Mount to /mnt/mr check manually and reboot to ensure it can be read fine:

    ERROR: Mounting on /mnt/mr worked just fine but after the reboot, nothing mounted and subsequent lvm pvs, lvm vgs and lvm lvs all resulted in:

  31. So my data was toast at which point I learned the very important commands the various online wiki's never informed me about: vgcfgbackup and vgcfgrestore. Unfortunately, I HAD NOT USED THE BACKUP.

    WARNING: My system was toast at this point and I had no way to recover the data because I did not have the LVM restore files.

    NOTE: Please read the post LVM: Recovering a lost volume. The below steps actually overwrote the VolGroup definitions as they were stored on the disk. I was not aware that the VG definitions were stored at the head of the partition before attepting step 32. DO NOT DO

  32. A BAD ATTEMPT TO RECOVER. THIS STEP WILL PERMANENTLY DESTROY THE DATA ON THE DISK. TRY ONLY IF YOU ARE PRACTICING.

    Here, we will try to recover our lost data by rebuilding the config backup we should have done earlier. We will try to rebuild the backup config manually from screen printouts we took earlier. First, we will recreate the basic structure we had earlier. Then, we'll modify this backup config with the same UUID's as in the original configuration.

    lvm pvcreate /-u x0O0xW-TAXH-Vrz2-g299-pJm6-Mj5g-srkOBH –setphysicalvolumesize 47871e –norestorefile /dev/sda3

    lvm vgcreate VolGroup /dev/sda3

    lvm lvcreate –extents 8192 –name lv_root VolGroup
    lvm lvcreate –extents 1024 –name lv_swap VolGroup
    lvm lvcreate –extents 38655 –name LogVol02 VolGroup

    We will now copy the VG backup from /etc/lvm/backup/VolGroup to our remote host so we can adjust the UUID's from the screen prints we took earlier. (Copy and paste is cumbersome on the recovery console or I simply do not know an easier way.)

    scp /etc/lvm/backukp/VolGroup root@192.168.1.1:/recovery/

    Once we adjust the VolGroup backup file, we will use the vgcfgrestore option to recreate it with updated UUID numbers.

    Please see the link below for recovering at this point the proper way:

    LVM: Recovering a lost volume.

  33. Now that we have recovered the LVM, I'll be sure to take backups of /etc/lvm/backup/<VOLUME GROUP> to any remote host. This way data can be recovered when needed instead of trying to recover the hard way.
  34. After the above recovery, the partition is now in an extended state over /dev/sda2 and /dev/sda3, two partitions apart by about 1TB of data. Having tried the faulty pvmove method above, we won't retry it here. Instead we will shrink the partition back to /dev/sda2 and create a backup partition on /dev/sda3 of the same size as /dev/sda2. Then we will rsync / scp data between the two instead. Should be safer.
  35. Here is the list of steps:

    # lvm pvcreate /dev/sda3
    # lvm vgcreate VGEntertain /dev/sda3
    # lvm lvs –help
    # lvm lvs –units s
    LV VG Attr LSize Origin Snap% Move Log Copy% Convert
    LogVol02 VolGroup -wI-a- 316661760S
    lv_root VolGroup -wI-a- 67108864S
    lv_swap VolGroup -wI-a- 8388608S

    # lvm lvcreate -L316661760S -n oLogVol02 VGEntertain
    # lvm lvcreate -L67108864S -n olv_root VGEntertain
    # lvm lvcreate -L8388608S -n olv_swap VGEntertain
    # lvm lvs –units s

    LV VG Attr LSize Origin Snap% Move Log Copy% Convert
    oLogVol02 VGEntertain -wi-a- 316661760S
    olv_root VGEntertain -wi-a- 67108864S
    olv_swap VGEntertain -wi-a- 8388608S
    LogVol02 VolGroup -wI-a- 316661760S
    lv_root VolGroup -wI-a- 67108864S
    lv_swap VolGroup -wI-a- 8388608S

    # lvm vgchange VGEntertain -a y
    # mke2fs -ext4 /dev/VGEntertain/oLogVol02
    # mke2fs -t ext4 /dev/VGEntertain/oLogVol02
    # mount /dev/VolGroup/LogVol02 /mnt/mr
    # mkdir /mnt/rr
    # mount /dev/VolGroup/lv_root /mnt/rr
    # mkdir /mnt/sr
    # mount /dev/VolGroup/lv_swap /mnt/sr
    # mkswap /dev/VGEntertain/olv_swap
    # mke2fs -t ext4 /dev/VGEntertain/olv_root
    # df -T

    Filesystem Type 1K-blocks Used Available Use% Mounted on
    /dev tmpfs 2026840 224 2026616 1% /dev
    none tmpfs 256000 129212 126788 51% /tmp
    /dev/loop0
    squashfs 128896 128896 0 100% /mnt/runtime
    /dev/mapper/VolGroup-LogVol02
    ext4 154818540 124239716 22714504 85% /mnt/mr
    /dev/mapper/VolGroup-lv_root
    ext4 33027952 13555808 17794424 44% /mnt/rr

  36. At this point, knowing that my VG's and LV's were recovered, I rebooted to my old installation to take advantage of the GUI and Konsole to copy things between the two VG's I created a number of mount points and mounted each VG:

    # mkdir /mnt/omr /mnt/orr /mnt/osr

    # mount /dev/VGEntertain/oLogVol02 /mnt/omr
    # mount /dev/VGEntertain/olv_root /mnt/orr
    # mount /dev/VGEntergain/olv_swap /mnt/osr

    # mount /dev/VolGroup/LogVol02 /mnt/mr
    # mount /dev/VolGroup/lv_root /mnt/rr
    # mount /dev/VolGroup/lv_swap /mnt/sr

  37. Next is to sync the two volumes together. For this I used rsync and went to sleep. The process completed overnight:

    EX: rsync -avh <SOURCE> <TARGET>

    # rsync -avh /mnt/mr /mnt/omr

    Repeat the same thing for the other mounted folders.

  38. Now we should also take a backup of the boot partition. For this again we can use dd. The below steps highlight the process. The most important thing below is that the two blue parts below have to match and the two green parts below have to match once you copy things over. Ideally, you want to save the new dd image file in the backup volume so it is not destroyed when we install the new OS:

    # parted /dev/sda unit s print free
    Model: ATA WDC WD15EADS-32R (scsi)
    Disk /dev/sda: 2930277168s
    Sector size (logical/physical): 512B/512B
    Partition Table: msdos

    Number Start End Size Type File system Flags
    1 63s 409662s 409600s primary ext4 boot
    2 409663s 392570943s 392161281s primary lvm
    392570944s 2538115886s 2145544943s Free Space
    3 2538115887s 2930277167s 392161281s primary lvm

    #
    # dd if=/dev/sda1 bs=512 count=409600 of=./boot-partition.sda1
    409600+0 records in
    409600+0 records out
    209715200 bytes (210 MB) copied, 9.41159 s, 22.3 MB/s
    # ll
    total 204824
    3407876 drwx-- 2 root root 4096 Mar 9 2010 lost+found
    3407874 drwx-- 4 root root 4096 Jun 13 2010 .Trash-0
    3407875 drwxr-xr-x 20 root root 4096 Aug 31 21:57 Files
    3407877 drwx-- 47 videouser videouser 4096 Sep 2 14:01 videouser
    262145 drwxr-xr-x 10 root root 4096 Sep 24 01:39 ..
    2 drwxr-xr-x 6 root root 4096 Sep 25 21:27 .
    11 -rw-r–r– 1 root root 209715200 Sep 25 21:27 boot-partition.sda1
    # parted /dev/sda unit b print free
    Model: ATA WDC WD15EADS-32R (scsi)
    Disk /dev/sda: 1500301910016B
    Sector size (logical/physical): 512B/512B
    Partition Table: msdos

    Number Start End Size Type File system Flags
    1 32256B 209747455B 209715200B primary ext4 boot
    2 209747456B 200996323327B 200786575872B primary lvm
    200996323328B 1299515334143B 1098519010816B Free Space
    3 1299515334144B 1500301910015B 200786575872B primary lvm

  39. The last thing you want to check is if saving the boot partition above worked properly by mounting it using the loopback device on some free directory:

    # mount /mnt/omr/boot-partition.sda1 /mnt/orr/ -o loop

    If all went according to plan, you should be able to browse the newly created dd out file from the mountpoint /mnt/orr in above example.

  40. At this point we are ready to install any new OS over the original VG's and PV's since a backup already exists of them.

    IMPORTANT: Don't forget to take a backup of the VG groups as defined from /etc/lvm/backup/VolGroup and /etc/lvm/backup/VGEntertain per the above.

How To Resize ext3 Partitions Without Losing Data

Version 1.0
Author: Falko Timme <ft [at] falkotimme [dot] com>
Last edited 12/31/2006

This article is about resizing ext3 partitions without losing data. It shows how to shrink and enlarge existing ext3 partitions and how to merge two ext3 partitions. This can be quite useful if you do not use LVM and you realize that your existing partitioning does not meet your actual needs anymore.

There are many ways of achieving this goal but this is the way I take. I do not issue any guarantee that this will work for you!

1 Preliminary Note

(I run all the commands in this tutorial as the root user, so make sure you're logged in as root. If you are on a Ubuntu system, you can become root like this:

sudo su

)

I have tested this on a Ubuntu Edgy Eft desktop system that has all files in one large partition (around 10 GB, device /dev/sda1). The partitioning looks like this:

df -h

Filesystem Size Used Avail Use% Mounted on
/dev/sda1 9.5G 4.1G 4.9G 46% /
varrun 94M 132K 94M 1% /var/run
varlock 94M 0 94M 0% /var/lock
udev 10M 52K 10M 1% /dev
devshm 94M 0 94M 0% /dev/shm
lrm 94M 18M 77M 19% /lib/modules/2.6.17-10-generic/volatile

The partition that is to be resized must be unmounted when we do the resizing; obviously this is not possible if this is the partition that holds all important system files like in this example. Therefore we download a Live Linux-CD such as Knoppix from which we boot later on (if you have physical access to the system). If it is a remote system that you don't have physical access to, you need a rescue system on that system (a lot of hosting companies offer dedicated servers with rescue systems nowadays) that you can boot into (instead of Knoppix), and this rescue system must have the following tools: fdisk, umount, fsck, tune2fs, e2fsck, resize2fs.

If the partition that you want to resize doesn't hold any system files (such as /home partitions, partitions for backups, etc.), you don't need a Knoppix Live-CD or a rescue system, because all steps can be run from the original system.

If you want to resize partitions on production systems, please back up your data before, because it is possible you lose all your data if you don't calculate the size of your new partition correctly (especially when shrinking a partition)! You have been warned! Tutorials about backups can be found here: http://www.howtoforge.com/taxonomy_menu/1/34

I'm going to resize /dev/sda1 in this tutorial. If your partition is named differently, please replace /dev/sda1 with your own device (e.g. /dev/hda5, /dev/sdb3, etc.).

2 Shrinking An ext3 Partition

This chapter is about shrinking an ext3 partition. I want to shrink /dev/sda1 in this example. First we gather some details on our original system:

df

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 9859036 4234908 5123304 46% /
varrun 95480 132 95348 1% /var/run
varlock 95480 0 95480 0% /var/lock
udev 10240 52 10188 1% /dev
devshm 95480 0 95480 0% /dev/shm
lrm 95480 17580 77900 19% /lib/modules/2.6.17-10-generic/volatile

df -B 4k

Filesystem 4K-blocks Used Available Use% Mounted on
/dev/sda1 2464759 1058727 1280826 46% /
varrun 23870 33 23837 1% /var/run
varlock 23870 0 23870 0% /var/lock
udev 2560 13 2547 1% /dev
devshm 23870 0 23870 0% /dev/shm
lrm 23870 4395 19475 19% /lib/modules/2.6.17-10-generic/volatile

df -h

Filesystem Size Used Avail Use% Mounted on
/dev/sda1 9.5G 4.1G 4.9G 46% /
varrun 94M 132K 94M 1% /var/run
varlock 94M 0 94M 0% /var/lock
udev 10M 52K 10M 1% /dev
devshm 94M 0 94M 0% /dev/shm
lrm 94M 18M 77M 19% /lib/modules/2.6.17-10-generic/volatile

fdisk -l


Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 1247 10016496 83 Linux
/dev/sda2 1248 1305 465885 5 Extended
/dev/sda5 1248 1305 465853+ 82 Linux swap / Solaris

fdisk -s /dev/sda1

10016496

Then we shut down the system and boot into our Knoppix Live-CD (or your rescue system) (if the partition you want to resize doesn't hold any system files, you can do everything from the original system; the steps are the same, just omit booting into Knoppix/your rescue system).

shutdown -r now

After Knoppix has booted, open a terminal and become root by running

su

/dev/sda1 should be unmounted by default, but you can run

umount /dev/sda1

to go sure.

Then run

fsck -n /dev/sda1

The output looks like this:

fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
/dev/sda1: clean, 159037/1254176 files, 1095299/2504124 blocks

Next we remove the journal from /dev/sda1, thus turning it into an ext2 partition:

tune2fs -O ^has_journal /dev/sda1

The output looks like this:

tune2fs 1.38 (30-Jun-2005)

Then run

e2fsck -f /dev/sda1

e2fsck 1.38 (30-Jun-2005)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: 164178/1254176 files (0.6% non-contiguous), 1051617/2504124 blocks

Now we resize our file system with resize2fs. resize2fs can resize ext2 file systems, but not ext3 file systems, that's why we had to turn /dev/sda1 to ext2. Currently, 4.1GB are used on /dev/sda1 (see the df -h output above), So it's safe to shrink it from 10GB to about 6GB (if you make it smaller than 4.1GB, you will lose data!). Therefore we run

resize2fs /dev/sda1 6000M

The output is as follows:

resize2fs 1.38 (30-Jun-2005)
Resizing the filesystem on /dev/sda1 to 1536000 (4k) blocks.
The filesystem on /dev/sda1 is now 1536000 blocks long.

Please take note of the amount of blocks (1536000) and their size (4k). We need that soon.

Now we delete our /dev/sda1 partition (don't be afraid, no data will be lost) and create a new, smaller one (but still big enough to hold our resized file system!). We can do this with fdisk:

fdisk /dev/sda

(Yes, it's /dev/sda, not /dev/sda1.)

The number of cylinders for this disk is set to 1305.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Type m to get a list of all commands:

Command (m for help): m
Command action
a toggle a bootable flag
b edit bsd disklabel
c toggle the dos compatibility flag
d delete a partition
l list known partition types
m print this menu
n add a new partition
o create a new empty DOS partition table
p print the partition table
q quit without saving changes
s create a new empty Sun disklabel
t change a partition's system id
u change display/entry units
v verify the partition table
w write table to disk and exit
x extra functionality (experts only)

Now we delete partition no. 1 (/dev/sda1):

Command (m for help): d
Partition number (1-5): 1

Next we create a new /dev/sda1 partition. It was a primary partition before, so we choose p again, and again it is our partition no. 1:

Command (m for help): n
Command action
l logical (5 or over)
p primary partition (1-4)
p
Partition number (1-4): 1

Now comes the crucial part - we are asked about the size of the new partition. The first cylinder is no problem, it is the one from the fdisk -l output at the beginning of this chapter (1).

First cylinder (1-1305, default 1): 1

But we don't have a value for the last cylinder of our new partition. Fortunately, we can specify the size in kilobytes (K), so we calculate the size like this:

We multiply the amount of blocks from the resize2fs output (1536000) by the size of a block (4k), and to go sure the partition is big enough, we add 3 to 5% to it (3% was enough for me, but if you want to go sure take 5%):

1536000 * 4k * 1.03 = 6328320k

So we prepend that value with a + sign and replace the small k with a capital one (K) and enter it:

Last cylinder or +size or +sizeM or +sizeK (1-1247, default 1247): +6328320K

Our original /dev/sda1 had the bootable flag (see the fdisk -l output from the beginning of this chapter), so we must add it to our new /dev/sda1 again:

Command (m for help): a
Partition number (1-5): 1

Now let's write our new partition table and exit fdisk:

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

Now we reboot the system, and again we boot into our Knoppix system (rescue system; original system if resized partition doesn't hold system files):

shutdown -r now

Become root again (on Knoppix run

su

)

and then run this:

fsck -n /dev/sda1

The output should look like this:

fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
/dev/sda1: clean, 159036/765536 files, 1047239/1536000 blocks

Then we create the journal on our new /dev/sda1, thus turning it into an ext3 partition again:

tune2fs -j /dev/sda1

tune2fs 1.38 (30-Jun-2005)
Creating journal inode: done
This filesystem will be automatically checked every 30 mounts or
0 days, whichever comes first. Use tune2fs -c or -i to override.

Now we are done. Shut down the system and boot into the original system:

shutdown -r now

If everything goes well, the original system will boot up, and no data has been lost. Now we can gather some details about our new partitioning and compare them with the information we collected at the beginning of this chapter:

df

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 6047868 4224140 1639408 73% /
varrun 95480 132 95348 1% /var/run
varlock 95480 0 95480 0% /var/lock
udev 10240 52 10188 1% /dev
devshm 95480 0 95480 0% /dev/shm
lrm 95480 17580 77900 19% /lib/modules/2.6.17-10-generic/volatile

df -B 4k

Filesystem 4K-blocks Used Available Use% Mounted on
/dev/sda1 1511967 1056035 409852 73% /
varrun 23870 33 23837 1% /var/run
varlock 23870 0 23870 0% /var/lock
udev 2560 13 2547 1% /dev
devshm 23870 0 23870 0% /dev/shm
lrm 23870 4395 19475 19% /lib/modules/2.6.17-10-generic/volatile

df -h

Filesystem Size Used Avail Use% Mounted on
/dev/sda1 5.8G 4.1G 1.6G 73% /
varrun 94M 132K 94M 1% /var/run
varlock 94M 0 94M 0% /var/lock
udev 10M 52K 10M 1% /dev
devshm 94M 0 94M 0% /dev/shm
lrm 94M 18M 77M 19% /lib/modules/2.6.17-10-generic/volatile

fdisk -l


Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 789 6337611 83 Linux
/dev/sda2 1248 1305 465885 5 Extended
/dev/sda5 1248 1305 465853+ 82 Linux swap / Solaris

fdisk -s /dev/sda1

6337611



Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019