7

When doing a default install of RHEL5 and higher (at least - don't recall if it has done it longer), Anaconda will setup your drives into a logical volume group - even if there is only one drive.

What is the purpose/reasoning behind using LVM atop a single drive? I understand why you would want to over RAIDed drives or across multiple disks of [potentially] different sizes, but not if there is only one disk.

Is it merely to provide for the opportunity to add additional space down the road if you happen to change your mind about how much space a given machine should have assigned to it?

1
  • 1
    flexibility of course Nov 10, 2011 at 21:37

2 Answers 2

11

My personal opinion is that all modern operating systems should have volume management of some kind. Like you said, one purpose is to ensure you can increase the data in the future beyond physical limitations of the disk. Including (althoguh quickly becoming irrelevent) DOS partition limitations.

Another good reason is in the case of imminent disk failure (S.M.A.R.T starts to indicate failure), you can plug in another disk, add it to the volume group, then pvmove all your data over to that disk -- in theory its possible to do this on a live system however I probably wouldn't do this! This greatly simplifies these kinds of operations.

Other than that, LVM can be useful for backups, the snapshot feature lets you do some pretty smart things with, say a database to ensure consistent backups. So you can in MySQL for example..

  • Flush all tables with a read lock and get master binlog position.
  • Create an LVM snapshot.
  • Unlock the tables.
  • Backup the contents of the MySQL data directory you just snapshotted, along with your master binlog position.
  • Destroy the snapshot.

Low-impact consistent MySQL point in time backups with little effort on your part.

Much of what LVM can do though is going to be being superceded by btrfs which has in-built volume management anyway, but as it stands now I think the possibilities you get with LVM make it a no-brainer for enabling by default.

The downside to this is it can be a little more trickier to rescue from, but its one of those things you figure out once and remember. More importantly though you lower consistency of your data. Not all LVM implementations support filesystem barriers for example and that might be worth something to you depending on what your doing with your system.

2
  • 1
    Why would you not recommend a pvmove on a live system? Because of the additional I/O, or are you worried about the reliability of pvmove? Personally I've done it a dozen times on live non-production systems, without any issues. Nov 10, 2011 at 22:27
  • Not really for I/O. Mainly because I only really pvmove from a faulty drive so it doesnt help to keep seeking the head randomly when pvmove it trying to do a sequential read of the data. Be it that random seeks is a little higher risk. I wouldnt really have a problem doing it on a system say that physically was running out of disks I could put in it and I was pvmoving to add a larger disk. Nov 10, 2011 at 22:32
0

I can't speak definitively as to why, but isn't the ease of future expansion a good enough reason on its own?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .