Removing a disk from a Logical Volume set

Has your favorite Linux distribution changed its default partitioning scheme to a logical volume layout? Why did they do this, and what does it mean?

Put simply, logical volumes let you grow a filesystem by making multiple physical partitions look like a single logical partition. Cool, huh? If you keep filling up /var, you can splice some more space into it! But if you lose one of the disks of your volume set, you’ll be thinking differently about this method of storage.

Pros and cons aside, one task I don’t find well documented is the job of “deconstructing” a volume group after a default installation creates one. If you’re only using one disk, it’s not much of an issue, but if you end up with a volume group spread across two disks and really wish you could handle those disks separately, you’ve got a tricky process to deal with.

Let me give this a shot:

Step 1: Moving Data
You’re going to need to move data from the logical volume so you can shrink it. I have to leave it to you how you want to do this. In my case, workstations were set up with an 80 GB drive originally, and a 750 GB drive was added later, unfortunately in a volume group configuration. I say unfortunately because damage to one disk results in pretty much total loss of data, and the researchers I support only had to experience it once to insist that volume groups be gone, or at least dependant disks.

So in my case I removed the contents of /home, which was the largest mass of data.

Run a df command once you’ve reduced your data to be sure it will fit:
df –h

Once I had less than 80 GB of data total, I knew it would fit on the original disk. Adjust your goals as necessary.

Step 2: Resize the filesystem
If you’re using ext2/ext3, this is a snap. In fact, you can grow (not shrink) ext filesystems while they are live (an impressive trick). But we’re shrinking the filesystem, so it’ll have to be offline.

I’m working on CentOS in this case, so I booted to the live DVD and at the boot prompt entered:
linux rescue

When it asks to scan the filesystems, click “Skip”.

If you’re not familiar with resizing ext filesystems, take a look at this great article on HowToForge: “How To Resize ext3 Partitions Without Losing Data”,

Or for a quicker set of instructions, go to “System Recovery Week: Using LVM In Rescue Mode”, at

One critical thing to note is that while you’re in rescue mode, you’ll have to preface the usual commands (vgscan, lvcreate, etc.) with their actual binary name, lvm.

The short version: run these commands:

lvm vgscan  
# to find VGs

lvm vgchange –ay 
# to activate VGs

lvm lvs
# to list logical volumes

e2fsck -f /dev/VolGroup00/LogVol00
# you have to run a filesystem check first

resize2fs /dev/VolGroup00/LogVol00 75G
# to shrink the filesystem down to a size that will fit on your disk, in my case 80 GB

lvm lvresize VolGroup00/LogVol00 –size 76G
# to shrink the logical volume; note the slightly larger size

resize2fs /dev/VolGroup00/LogVol00
# to grow the filesystem to fit the logical volume space; note not size specified

lvm pvmove /dev/sdb1
# to remove sdb1 from the logical volume; note this may be a partition, or a whole disk, e.g. sdb

vgreduce VolGroup00 /dev/sdb1
# to remove sdb1 from the entire volume group

See this discussion for a review of removing disks from an LVM at The Linux Documentation Project:

At this stage, the volume group was entirely contained on my 80 GB drive, leaving the 750 GB drive to be fdisked with a single partition.
I moved my backed-up data from /home onto this new partition, mounted it as /home, and changed /etc/fstab to make it permanent.

Now my researchers can take their own data disk from any machine, should that machine die, and be able to access their data by putting that drive in any other machine. This is less high-tech than using volume management – and a whole lot less fragile!