Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have to migrate a few servers to Linux, and one important aspect that I need to evaluate is that my new host system must have elastic storage capacity. Naturally, doing some basic research, I came across LVM.

Is there any performance penalty for using lvm? If so, how can I measure it?

What I am considering right now is to have Linux as a host OS with LVM and virtualized Linux boxes running on top of it (should I add LVM on the guest OS as well?).

share|improve this question
up vote 77 down vote accepted

LVM is designed in a way that keeps it from really getting in the way very much. From the userspace point of view, it looks like another layer of "virtual stuff" on top of the disk, and it seems natural to imagine that all of the I/O has to now pass through this before it gets to or from the real hardware.

But it's not like that. The kernel already needs to have a mapping (or several layers of mapping actually) which connects high level operations like "write this to a file" to the device drivers which in turn connect to actual blocks on disk.

When LVM is in use, that lookup is changed, but that's all. (Since it has to happen anyway, doing it a bit differently is a negligible performance hit.) When it comes to actually writing the file, the bits take as direct a path to the physical media as they would otherwise.

There are cases where LVM can cause performance problems. You want to make sure the LVM blocks are aligned properly with the underlying system, which should happen automatically with modern distributions. And make sure you're not using old kernels subject to bugs like this one. Oh, and using LVM snapshots degrades performance (and increasingly so with each active snapshot). But mostly, the impact should be very small.

As for the last: how can you test? The standard disk benchmarking tool is bonnie++. Make a partition with LVM, test it, wipe that out and (in the same place, to keep other factors identical) create a plain filesystem and benchmark again. They should be close to identical.

share|improve this answer

LVM, like everything else, is a mixed blessing.

With respect to performance, LVM will hinder you a little bit because it is another layer of abstraction that has to be worked out before bits hit (or can be read from) the disk. In most situations, this performance hit will be practically unmeasurable.

The advantages of LVM include the fact that you can add more storage to existing filesystems without having to move data around. Most people like it for this advantage.

One disadvantage of LVM used in this manner is that if your additional storage spans disks (ie involves more than one disk) you increase the likelyhood that a disk failure will cost you data. If your filesystem spans two disks, and either of them fails, you are probably lost. For most people, this is an acceptable risk due to space-vs-cost reasons (ie if this is really important there will be a budget to do it correctly) -- and because, as they say, backups are good, right?

For me, the single reason to not use LVM is that disaster recovery is not (or at least, was not) well defined. A disk with LVM volumes that had a scrambled OS on it could not trivially be attached to another computer and the data recovered from it; many of the instructions for recovering LVM volumes seemed to include steps like go back in time and run vgcfgbackup, then copy the resulting /etc/lvmconf file to the system hosting your hosed volume. Hopefully things have changed in the three or four years since I last had to look at this, but personally I never use LVM for this reason.

That said.

In your case, I would presume that the VMs are going to be relatively small as compared to the host system. This means to me you are more likely to want to expand storage in a VM later; this is best done by adding another virtual disk to the VM and then growing the affected VM filesystems. You don't have the spanning-multiple-disks vulnerability because the virtual disks will quite likely be on the same physical device on the host system.

If the VMs are going to have any importance to you at all, you will be RAID'ing the host system somehow, which will reduce flexibility for growing storage later. So the flexibility of LVM is probably not going to be required.

So I would presume you would not use LVM on the host system, but would install VMs to use LVM.

share|improve this answer
@DM - You seem to have skipped mentioning that an LVM2 physical volume may be any block device, including md-RAID. I.E: pvcreate /dev/md0 regardless of what the underlying RAID type /dev/md0 is. So if your /dev/md0 happens to be a RAID array of mirrored physical disks... It is sort of hard for the loss of a single physical drive to affect your LVM2 group. Also: You can use a LVM2 logical volume(s) as the media side when creating a RAID array. Both operate at the device mapper level, both are device-in / device-out layers. – user13719 Dec 27 '11 at 22:27
your recovery concerns are excessive, it is trivial to move a lvm array between computers with a reasonably recent linux distro (i.e. debian oldstable is new enough) – hildred Jan 14 '14 at 13:33
@user13719: yes, you can LVM any block device, but in practice people don't do this. They end up with a single drive LVM'd. Then they add another drive, and use LVM to extend the existing file system onto the new disk. At that point, the failure of either disk will kill the LVM. – David Mackintosh Feb 11 '14 at 21:59
@hildred, the above is what I was referring to -- I am not aware of any tools that can recover data from a LVM that spans multiple disks (block devices) with one disk missing. – David Mackintosh Feb 11 '14 at 22:00

In general: If you add a new layer of complexity ("aka more to do") nothing will be faster. Note: You only add work and not 'change' they way the work is done.

How can you measure something? Well, you create one partition with LVM and one without, then use a normal benchmark and just run it. Like the folks at


As it seems, only slightly impact to the speed. That seems to by in sync with the findings of someone else who ran a benchmark:


But just benchmark it on your own and see if your hardware and the OS you want to use behave the same and if you can ignore the (maybe slightly) impact of an additional layer of complexity which gives you elastic storage.

Should you add LVM to the guest OS: That depends on if you need the guest OS to have elastic storage as well, doesn't it? Your needs dictate what you have to deploy.

share|improve this answer
@akria, oops, it's been moved – hildred Jan 14 '14 at 13:38
You certainly can change how work is done. For example, I can give you directions to a location via GPS coordinates, or by streetnames, or by local landmarks. Different ways, but you still have to walk the same path. The time it takes to look at a paper map vs. following your phone's instructions may differ slightly, but ultimately it's negligible compared to the walking time. – mattdm Feb 4 '15 at 16:05
I already stated that the impact of the added work in the case of lvm has no real impact. I wonder, what the point is you are driving at? – akira Feb 4 '15 at 16:10
The point I am "driving at" is that "Note: You only add work and not 'change' they way the work is done" is not a factual statement. – mattdm Feb 13 at 19:26
@mattdm: it's obvious, that if you change the way the work is done (eg, another algorithm, another fs etc), that you then get different results. lvm is not changing the way the fs works. you know that. and that is why i am wondering what your point actually is? "add a layer of something" means "adding", not "changing the other thing as well". you know that as well. – akira Feb 14 at 20:51

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.