******************************************************************

World of LVM: Part I
World of LVM: Part II

******************************************************************

Have you ever asked yourself any of these questions?

1. Why did I size this filesystem <randomsize> only?

2. Where the hell do I mount the new disk(s)?

3. Is there any way to dinamically increase this filesystem?

Then, LVM (Logical Volume Manager) may help you!

(Yay! I always wanted to begin an article with this crappy intro!)

Now, seriously speaking, LVM is one of the most useful tools for disk and volume management. It lets you increase/decrease partitions on the fly, use different physical disks, perform snapshot based backups and simpligy storage management in your servers.

We are going to see, in three articles, how it works (part I), how to use it in 2 diffrent *NIXes (part II) and how to use it for backing up databases in a flash by using snapshots (part III).

So, now, get ready for the theory, it's time to discover...

how does LVM work?

LVM divides storage into 4 different layers: physical discs, volume groups, logical volumes and filesystems. In other words, it adds 2 new abstraction layers to the storage world.

Volume groups (VG) are groups of one or more physical disks.

Whenever you create a new volume group you specify the size of its segments. Those segments are called “Physical Extents (PE)”. It is important to carefully choose the size and the maximum amount of PEs of a new Volume Group, as this will impact in:

• the maximum capacity of the Volume group

• the internal defragmentation of the data in that VG (we'll talk about this later)

You use a bunch of PEs to create Logical Volumes (LV). You can have more than one Logical Volume in a Volume Group. And you can assign new PEs to a Logical Volume at any time if the Volume Group has unassigned PEs. This way you can dinamically increase the size of a Logical Volume at any time.

If you use all the PEs of a Volume Group, you just have to add a new physical disk to the VG to get new free PEs to increase the size of your Logical Volumes. Until you reach the Max amount of PEs of the Volume Group.

Finally, the filesystem is the format that you decide to give to a logical volume: it can be JFS, XFS, ReiserFS, vxfs, EXT3, a swap... whatever you need, depending on the OS and the kind of data you are going to place on the filesystem.

Disadvantadges of LVM

LVM is not a magical solution for all of our storage problems, it turns out, actually, that it may become a problem in some situations.

1. Recovery:fix a system based in LVM is not as easy as the classical partition system. You need to use a recovery tool that supports the new system and reconfigure the volume group. It'll need another series of articles to describe how to recover a corrupted LVM system.

2. Boot:in HP-Ux it's not a problem (I can't tell for the rest of comercial unixes) but for x86 (64 or 32) gnu/linux, you have to leave /boot outside the LVM and take certain considerations when setting the startup of the OS.

3. Fragmentation: the flexibility of dinamically assigning PEs at your will has a side effect, a logical volume may have non-contiguous storage if it's sharing a Volume Group with another LVs. That's why the chunks (the PEs) are at least 4Mbyte big.

So, before deciding if you should use LVM, take in account the following:

• Do your system need filesystem increases regullarly?
• Is your data expanding fast?
• Are you planning to migrate your data to a SAN(1)?
• Do your have a huge database that can't be backed up online within an acceptable timeframe?

If you answered yes to the previous questions, then you should start using LVM.

1: SAN is an Storage Area Network, in short, a network, usually linked via Fibre Channel, dedicated to provide storage to one or more systems. If your database is growing beyond 500GB it's quite possible that you may want to study the possibility of using this technology.

some reads, until the next part appears...

Wikipedia entry regarding LVM

LVM2 at RedHat