Jump to content

Obsolete:LVM

From Wikitech

Keep free space!

I noticed that people still use LVM and allocate all available space at once during installing new servers. Please don't ever do that.

When using LVM (and you should, if the server stores any data of even moderate importance), NEVER allocate more than say 90% of available disk space. And even less if you know it's not going to need more than a given amount. But in any case, keep at least 5-10% free.

Here's why

  • XFS cannot (easily) *shrink*, whereas it can easily and quickly *grow* even when used online. With one quick command. For all filesystems, it's always easier to grow than to shrink.
  • No free space in the LVM Volume Group (VG) means you can't use snapshots. There's no space for the snapshots to put modified data.

Imagine we have a storage/logging/mysql server, constantly adding data. It (nearly) fills up. Nagios hopefully warns us. Sometimes it misses it. In either case, we may immediately need more disk space, or at least very soon. When we have some free space in LVM, we can instantly increase the Logical Volume a bit with one quick command for instant relief, and then look at procuring new hardware/more disk space. If we don't have free space, we're fucked. And why allocate that space until it's needed?

This has saved our arses a number of times already. It's very nice to fix an immediate emergency within a minute, and have some breathing room again. And I just don't see any reason NOT to do it. If you need that extra 10% space immediately, you most likely should have requested more storage from the start.

And LVM Snapshots, even when not planned during regular operation, can be Very Handy during emergencies, or migrations, or other unforeseen events. Why not keep a little bit of space available to make them possible?

Also, perhaps this server will get additional storage tasks later on. It may be good to have that in a separate Logical Volume for whatever valid reasons. If you've already used up all VG space for the other LV, and you can't easily shrink XFS, this isn't possible.

This sort of holds for NetApp aggregates too btw. NetApp aggregates can't shrink, and they extend easily. Therefore we keep them small, and add new disks in groups of 4 at a time to them as the need arises. The system volumes in them (really an abstract concept) can shrink/extend at will.

-- Mark (talk) 13:42, 17 August 2012 (UTC)

DB Snapshots

For LVM use in our database snapshot rotation see:

To grow an LVM partition

We use XFS for the data partition for our DBs, which makes growing the partition easy.

  1. Find out how much space is available with vgdisplay - look for Free PE / Size
  2. grow the partition a reasonable amount with lvextend -L800G /dev/mapper/data
    • lvextend's arguments are -L<new-size> and the path to the device as show by df
    • it's always nice to leave some empty space for when it fills next time if you can.
  3. grow the XFS partition to fill the newly available space on the logical volume with xfs_growfs /a
    • unlike lvextend, the argument to xfs_growfs is the path to the mountpoint for the partition.

To create a LVM partition

  1. First do a vgdisplay to find the name of the VG and make sure there is plenty of Free space.
  2. lvcreate -L size -n LVname VGname for example: lvcreate -L 16G -n logs neon
  3. mkfs -t ext3 /dev/VGname/LVname to format the new volume