Logical Volume Manager: A Beginner's Guide

Hey there, everyone!

I'm super excited to kick off my very first blog! Today, I want to take you on a journey into the awesome realm of Linux Volume Manager (LVM). Don't worry if you're new to this – I'll start from the very basics and walk you through the entire process of creating and managing your own LVM. And guess what? I promise to keep things fun and easy to understand. So, buckle up, and let's embark on this exciting adventure together! Ready? Let's go! 😊

Prerequisites

Before we get started, we would need a few tools at our disposal.

• 🖥️ A Linux machine with root access (VMs would suffice as well)
• 📀 A USB drive (preferably 8 GB and above)
• ☕ A cup of coffee (can't miss this one!)
• 🐧 Some understanding of Linux is always a plus!

Physical Volumes

As the name suggests, we would be dealing with volumes, to be precise, storage. For us to understand LVM better, we would need a firm understanding of how Linux stores data without LVM in the first hand. Let's start by inspecting how a regular hard disk drive or solid state drive (block devices)

The diagram above illustrates how a physical device or block device is partitioned and used by our Linux machines. At the top, there's a partition table, which is just a reflection of how the device is internally partitioned. The next three blocks represent the partitions, named in ascending order for easy understanding. Each partition has a filesystem, a special database that stores the file and folder hierarchy details**. Common examples of filesystems are ext4, NTFS, and FAT. Don't worry; we'll dive into filesystems and partitions in the hands-on section later!

Linux organizes its file system like a tree structure, with the / directory as the root. All files and folders reside next to it. In our setup, partition 1 is mounted to /, partition 2 to /tmp, and partition 3 to /home. When we store data in any directory, it goes into the corresponding partition.

However, using physical volumes directly comes with some problems:

• When the / directory runs out of space, extending it can be tricky.
• Incorporating a new storage device with your /home directory requires adjustments.
• Replacing a slow storage device is a cumbersome task.

That's where LVM comes to the rescue! It simplifies these processes and provides more flexibility. Let's explore LVM further in the upcoming sections.

Okay, so, what actually is LVM?

LVM, which stands for Logical Volume Manager, becomes more understandable now that we have a basic understanding of storage devices and their utilization. LVM acts as an intermediate layer, allowing us to manage our storage seamlessly. It adds flexibility and simplicity to the storage management process, making it easier to handle partitions and filesystems. With LVM, we can efficiently allocate, resize, and move logical volumes, providing us with a more dynamic and adaptable storage solution

As the diagram shows, LVM utilizes a Volume Group (VG) to abstract the Physical Volumes (PVs), which represent the raw storage devices like HDDs and SSDs. The VG is typically created with one or more PVs, and from this pool of storage, Logical Volumes (LVs) are carved out. The beauty of LVM lies in its ability to freely adjust the size of these LVs, thanks to its dynamic data management on the physical volumes. In a sense, the VGs act as a versatile and flexible data pool.

You may have noticed the block labeled /boot. This partition holds the data related to our system's boot process. At boot time, Linux cannot read data from the LVs directly, so a separate raw /boot partition is necessary.

It's important to note that not all LVM-based systems offer the same level of flexibility. Some systems may restrict us to just one PV and two LVs (for swap and root), limiting the benefits of LVM's true potential. However, when we have the liberty to leverage LVM's full capabilities, it opens up a world of possibilities for efficient and customizable storage management.

Operations supported in LVM

LVM supports the following operations:

• Add more physical volumes (PVs) to volume group (VG)
• Remove PVs as long as there is enough space to accomodate the existing logical volumes (LVs) into the VG.
• Resize LVs

Enough chit-chat, let's get to the real stuff!

Now that we have the theory out of the way, let's get our hands dirty by actually creating a LVM on our systems. We would be doing the following stuff:

1. Partition our USB drive to have 2 partitions (2 GB + ~6 GB).
2. Create a VG from 1 partition and, later on, extending it with the other partition.
3. Displaying the details of the VGs.
4. Create 2 LVs (1 GB + 2 GB)
5. Display the LVs
6. Create file systems on the LVs and mount them to our systems
7. Extend the 1 GB LV by 2 GB and re-adjusting the file system.
8. Removing the VGs and LVs.
9. Fixing out pendrives.

Just to make a note of it, some commands that I will be using might not be already present on your distro. In that case, please be sure to read the error messages and install the required binaries.

So turn on your Linux machine, get a sip of your coffee and get started!

Partitioning our USB drive

Just so we don't actually blow up our computers trying to do anything fancy, we would do this experiment using a USB drive. I am using an 8 GB HP stick for this. Just make sure to back up any data that is present in the USB drive and then we are good to go.

The first step is to partition the USB drive.

Make sure you are in a root shell. If not, use

sudo -i

Next, let's grab some details about our block devices.

lsblk

I have truncated the irrelevant details from the output. You can notice that there are 2 devices called sda and sdb. And under the TYPE column, you can also see that these are...disk. But wait, where did these names come from? Let's find out how.

Block devices use SCSI (Small Computer System Interface) to talk to processes on one side and hardware on the other side. Hence, block devices have device names (since everything on Linux is a file, so device files) starting with sd*, where s = SCSI and d = device. During boot time, the kernel detects block devices one by one and name them in the form sd[a-z]. So in my case, my vmware disk got detected first and hence, it was named sda. Next, after boot, I attached my USB stick and the kernel named it sdb. As I mentioned earlier, all disks have one or more partitions. In the above output, sdb1, sda1, etc. are names of partitions.
Note that USB devices use SCSI as a layer of abstraction over its USB interface. That's the reason why it gets detected as block devices.

We can fetch more details about our block devices using this command:

fdisk -l /dev/sdb

Now, we would partition the device into 2 halves. For that, we first need to unmount our device:

umount /dev/sdb1

To verify that the device is unmounted, you can run the following command:

mount | grep sdb

The output of this command should be empty.

Next, we will use fdisk to manage the partitions. Here is what we will do:

1. Delete the existing partition
2. Create a new partition of 2 GB
3. Create another partition of the remaining size
4. Save the changes (fdisk doesn't save the changes on the go)

To start, type the following command and refer to the output for more:

fdisk /dev/sdb

Commands used:

• d: Delete existing partition
• n: Create new partition
• p: List all partitions

Once done, you can verify the newly created partitions using:

lsblk /dev/sdb

Creating a volume group

Now that we are done with partitioning our USB drive, it's time to create our brand-new VG.

Before running any of the commands below, make sure you have installed the lvm2 package:

sudo apt install lvm2 -y

Next, we create our VG:

vgcreate myvg /dev/sdb1

Listing VGs

We can list the existing VGs in our system using the command:

vgs

OR

vgdisplay

The first command lists all the VGs in a compact manner, while the second command gives us a detailed view.

• VG: Name of the volume group
• #PV: Number of physical volumes associated with the VG
• #LV: Number of logical volumes inside the VG
• #SN: Number of snapshots of the VG
• VSize: VG Size
• VFree: Amount of unallocated space on the VG

If you have come this far, give yourself a pat on the back and have a sip from that cup of yours!

Adding PVs to VG

We want to add our /dev/sdb2 partition to myvg aswell.

vgextend myvg /dev/sdb2

Notice that if we list out our VG now, we would see that its size has changed:

vgs myvg

Creating logical volumes out of myvg

Our VG has been created. Now, we want to create volumes out of it so that we can start using it.

We will create a 1 GB volume named mylv1:

lvcreate --size 1g --name mylv1 myvg

And similarly, we will create another LV of size 2g, named mylv2:

lvcreate --size 2g --name mylv2 myvg

If we try to see our VG config now, we will see that the VFree has reduced now:

vgs myvg

Listing LVs

We have 2 LVs created and we would like to see how they look like. The command is similar to that of listing VGs:

lvs

Using our LVs

Okay, so now we have 2 LVs created and now we want to use them. Lets see how we can do that.

Previously, we saw that the kernel detects devices during boot time and assigns them the names accordingly. This means that our LV "device" names will also vary with each boot. Initially, the kernel creates the logical volumes under /dev folder with a naming convention dm-*, where * is an integer. To make sure we can map our LVs by the name we know them to these dm-* device files, the kernel also creates symbolic links under the /dev/mapper and /dev/<vgname> directories.

Contents of /dev/mapper:

Contents of /dev/myvg:

Now that we know what device files to use, let's actually create a file system:

mkfs -t ext4 /dev/myvg/mylv1

This command creates an ext4 file system on our mylv1 LV. Now its time to mount it to a location.

First, I'll create a mountpoint:

mkdir /mnt/mylv1

Then, I'll mount the LV:

mount /dev/myvg/mylv1 /mnt/mylv1

Next, I'll verify my mount point using:

mount | grep mylv1

As we can see, everything is set up exactly how we wanted it to be. If I were you, I would have tried to do the following things:

• Do the same for mylv2
• Take a break
• Take another sip from my cup

Using our newly created LV

First, we need to move to our mount point:

cd /mnt/mylv1

Next, we can inspect the size using:

df -h .

Lastly, we can start creating files. I'll leave this to you. But remember, this space is created by the root so no other user would have write access to it. If you want to give the users write access, then run chmod a+rw . while you are still in that directory.

Resizing the LV

Remember our mylv1 LV just has 1 GB of storage. We now would like to ramp it up to have 3 GB. Lets do that.

lvresize -L +2g myvg/mylv1

This command adds 2 GB of storage to mylv1.

But now if we run df -h /mnt/mylv1, we notice that the size didn't change. Did we make a mistake? No.
Remember that file systems are the managers of every partition? When we created a partition on mylv1, it's size was 1 GB. Just increasing the volume size doesn't mean that the filesystem would also be synchronized. So, to do that, we need to run the following command:

fsadm -v resize /dev/myvg/mylv1

Try running df -h /mnt/mylv1 and you will see that the size has increased.

lvresize provides us with a -r flag to automatically do the file system resizing for us. So, the command would be:

lvresize -r -L +2g myvg/mylv1

Removing LVs and VGs

We have almost reached the end of this long blog now. Before we finish, we would like to perfrom a clean-up.

First step is to unmount the LVs:

umount /dev/mylv1

Make sure you unmount mylv2 if you did mount it earlier.

Second step is to delete the LVs:

lvremove myvg/mylv1
lvremove myvg/mylv2

And at last, we will be deleting the VG:

vgremove myvg

I made the mistake of removing a LV before unmounting it, so I got an error.
After this command, you can issue vgs and lvs to confirm that everything is deleted.

Fixing our USB drive

Since I have already talked about partitioning and file systems, I won't be reiterating over them.
To get started, do:

fdisk /dev/sdb

Wallah! Your USB would now be fixed. With this, we come to the end of this blog.

Conclusion

In conclusion, Linux Volume Manager (LVM) serves as a crucial tool for flexible storage management. It abstracts raw storage devices (PVs) into logical volumes (LVs) within volume groups (VGs). LVM empowers us to resize LVs dynamically and handle storage with ease, providing a versatile storage solution. While some systems may limit its potential, utilizing LVM opens up possibilities for optimizing storage usage and system performance. Embrace the power of LVM in your Linux journey for seamless and efficient storage management. Happy computing!