LVM: Resizing an LV

In both my current job, and previous job LVM was not a tool we were able to use. In the previous job it was because the auto provisioning system simply would not work well with LVM. After the company went through a merger, we were able to get that added. But it was quite late in the game. In my current job, we use Debian Lenny, which did not provision with LVM. This drives me up a fucking wall. I can not stress enough why this is so important.

In case you have no idea what I am talking about. LVM stands for Logical Volume Manager. Instead of writing your file system to a partition, you put LVM on the partition, then you can chop up the volume, and group it however you want. In doing that you will create Logical Volumes. You then write your file system to the Logical Volume. The major gain here, is being able to resize a file system without the risk of losing it if you misaligned the blocks, file system, etc.

[root@media smb]# lvresize --help
  lvresize: Resize a logical volume

lvresize
        [-A|--autobackup y|n]
        [--alloc AllocationPolicy]
        [-d|--debug]
        [-f|--force]
        [-h|--help]
        [-i|--stripes Stripes [-I|--stripesize StripeSize]]
        {-l|--extents [+|-]LogicalExtentsNumber[%{VG|LV|PVS|FREE|ORIGIN}] |
         -L|--size [+|-]LogicalVolumeSize[bBsSkKmMgGtTpPeE]}
        [-n|--nofsck]
        [--noudevsync]
        [-r|--resizefs]
        [-t|--test]
        [--type VolumeType]
        [-v|--verbose]
        [--version]
        LogicalVolume[Path] [ PhysicalVolumePath... ]

[root@media smb]#

In the dark ages, we needed to shut the box down, boot it up using a live CD, and then make the changes to partition table. Using LVM, you only create one partition. So this is completely moot.

[root@media smb]# fdisk -l  /dev/sda

Disk /dev/sda: 107.4 GB, 107374182400 bytes
255 heads, 63 sectors/track, 13054 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b93ae

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          64      512000   83  Linux
/dev/sda2              64       13055   104344576   83  Linux
[root@media smb]#

As you can see, we have a boot partition, and a partition that holds LVM.

Now, rule of thumb: -If you are growing a file system, you can do this online. Yes, without even unmounting it. How cool is that? -If you are shrinking a file system, you need to unmount it.

The reason for this is, if you are writing to the file system, and you grow it, you get more room... Who cares? If you are shrinking, and the space you are trying to write to is no longer part of the file system... bad things happen.

It is important to note, that I am using the -r flag to automatically run resize2fs/fsck after the LV is resized. Basically, you need to resize the LV, and ALSO the file system held within the LV. Then just for safety sake, you run fsck. Using -r cuts down the three step process to a single step.

In this example. We have a /home directory we want to shrink by 30G. We want to re-allocate this to /.

Step 1: Unmount, and Shrink /home by 30G.

[root@media smb]# umount /home
[root@media smb]# lvresize -r -L -30G  /dev/mapper/vg_media-lv_home
fsck from util-linux-ng 2.17.2
/dev/mapper/vg_media-lv_home: 20/2990080 files (5.0% non-contiguous), 233719/11954176 blocks
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/mapper/vg_media-lv_home to 4089856 (4k) blocks.
The filesystem on /dev/mapper/vg_media-lv_home is now 4089856 blocks long.

  Reducing logical volume lv_home to 15.60 GiB
  Logical volume lv_home successfully resized
[root@media smb]# mount /home

Now lets confirm we shrank down /home to ~16G.

[root@media smb]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_media-lv_root
                       50G   15G   32G  32% /
tmpfs                 935M     0  935M   0% /dev/shm
/dev/sda1             485M   40M  420M   9% /boot
/dev/mapper/vg_media-lv_home
                       16G  169M   15G   2% /home
[root@media smb]#

Step 2: We don't need to unmount /, because we are growing this partition.

[root@media smb]# lvresize -r -L +30G /dev/mapper/vg_media-lv_root
  Extending logical volume lv_root to 80.00 GiB
  Logical volume lv_root successfully resized
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/mapper/vg_media-lv_root is mounted on /; on-line resizing required
old desc_blocks = 4, new_desc_blocks = 5
Performing an on-line resize of /dev/mapper/vg_media-lv_root to 20971520 (4k) blocks.
The filesystem on /dev/mapper/vg_media-lv_root is now 20971520 blocks long.

[root@media smb]#

Now that we have grown / by 30G. Lets check and make sure df reflects this change.

[root@media smb]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_media-lv_root
                       79G   15G   61G  20% /
tmpfs                 935M     0  935M   0% /dev/shm
/dev/sda1             485M   40M  420M   9% /boot
/dev/mapper/vg_media-lv_home
                       16G  169M   15G   2% /home
[root@media smb]#

As you can see, we successfully grew /, and shrunk /home. We didnt need to turn the server off, and if we had anything running out of /home we simply would have needed to stop it. But anything running on / would have been fine to leave running. Compare this to what you would have needed to do if we weren't using LVM. Good, now I assume you will use LVM going forward.

Other neat shit you can do with LVM: Use LVM Snapshots to create backups eg:MyLVMBackup CLVM (clustered logical volume manager) to cluster file systems between multiple boxen. Use LVM to mirror/stripe file systems to create a pseudo software RAID.