7

We have a big drive that we've split up using LVM. We allocated one segment to the root filesystem and several other segments to other filesystems. Then we wanted to add more space to the root filesystem, so we carved out another segment at the unallocated end and added it (meaning that the root filesystem is composed of two disjoint segments).

Lately we've been having some I/O performance issues and the thought is that the non-contiguous root volume could be to blame. We're considering moving things around to make the root volume one (contiguous) segment, in hopes of improving performance (the thought being that this will make it easier to access things).

Another school of thought is that LVM has this all sorted out and it's not going to make any difference (other than to make the graphic of the drive layout a bit more compact).

What's the likely penalty we're paying for the two-segment volume?

Improve this question
10
  • 1
    There's zero penalty, apart from the natural/physical ones (such as HDDs being faster near the beginning and slower near the end of the drive).
    – frostschutz
    Commented Feb 9, 2013 at 0:09
  • @frostschutz thanks-- can you point me at something that will help me make the case that there's nothing to worry about?
    – jhfrontz
    Commented Feb 9, 2013 at 1:18
  • 1
    Dunno, maybe this serverfault.com/questions/209461/lvm-performance-overhead -- but LVM does the same thing partitions do really. It's a simple address mapping logical:physical. Which is something that's done all the time and everywhere (each process has its own virtual address space too). For a LVM segment to cause any measurable overhead, the segment boundary would have to be in a particularly hot area (like the filesystem journal) for the extra HDD seek to make any difference. This case simply doesn't exist in practice.
    – frostschutz
    Commented Feb 9, 2013 at 1:54
  • If you can drill down your io-problem to a specific filesystem-place you can try to relocate that to its own LV. And yes - if that IO is on a place where physical drive haeads have to move a while there will be a penalty. But this is not the fault of the LVM.
    – Nils
    Commented Feb 9, 2013 at 20:58
  • 1
    There is a penalty, in terms of seek time. And LVM is another slice in the stack, that adds latency. But before going to heroic efforts, make sure your problem is really I/O, and where. If some data is accessed very frequently, perhaps it is worth it to give it a dedicated disk (or even SSD). If you have several disks, balance their load, distribute data that is "used together" to separate disks. Use sar (from sysstat) or even systemtap to find out what is going on.
    – vonbrand
    Commented Feb 11, 2013 at 3:35

2 Answers 2

Reset to default
3

There should be no appreciable performance hit from having non-contiguous blocks of PE's allocated to the same LV unless you're doing something really wacky like making your LV increments really small and growing a LV many times (while doing the same to many LV's in the same VG)--which would cause a great deal of fragmentation.

That said, any volume management system (LVM included) can make it possible to fragment reads that MIGHT otherwise be sequential, but I don't think that is the case here. If your filesystem is on a LV that is made up of only two non-contiguous allotments of extents that are otherwise contiguous, then it's definitely not going to cause a perceptible (and probably not even measurable) issue.

It's not guaranteed that your two allocations to that LV are contiguous, but they will be unless your VG had some fragmentation of its unallocated PE's. (this would only happen with frequent adding and removing of LV's to the same VG)

If it is cheap to do so, then you might consider defragmenting your LV by making a file-level backup and rebuilding the underlying VG from the PVs-on-up.

Improve this answer
4
  • 1
    Actually there is a performance hit to having multiple PVs on the same device. At least last I checked, LVM does not realize they are on the same spindle, so will try to stripe volumes across both PVs. If they actually are on the same spindle, then this will cause a seek storm. Also the second allocation to extend the root almost certainly will be discontiguous since the other volumes allocated after the root will have used up the space following the root.
    – psusi
    Commented Feb 21, 2013 at 20:54
  • If I'm understanding the terminology, I only have one PV (the whole drive is in the same partition). But we've created two different (non-contiguous) logical partitions (what I'm calling "segments" out of ignorance).
    – jhfrontz
    Commented Feb 21, 2013 at 23:14
  • @psusi, you are correct--I mixed up some terms in there. I made a clarification.
    – Iron Savior
    Commented Feb 22, 2013 at 2:27
  • @jhfrontz, in LVM terms, a Physical Volume (PV) is basically a pool of Physical Extents (PE). PE's are the smallest unit of space that can be allocated to a Logical Volume (LV). When a LV is created, it is assigned a number of unallocated PE's. Those blocks of PE's may or may not be contiguous. It is best that a PV spans the entire device (I prefer to also use a disk label with just one partition per device) because of the striping that psusi--although I believe you can disable striping in LVM, but the command to specify that escapes me right now.
    – Iron Savior
    Commented Feb 22, 2013 at 2:42
2

Having a logical volume split into multiple disjoint physical extents does have some overhead, in that the heads have to seek over the intervening gap. The overhead of a single seek however, is miniscule, so having the volume split in two chunks is not going to be anything you will notice in practice. If it is split in 1000+ chunks, then it could start to become a bit of a problem, but in practice, it won't get this bad.

Improve this answer
4
  • Isn't "have to see over the intervening gap" making an assumption about the physical layout of the disjoint physical extents? I mean, say they were mirror images on the opposite sides of the platter-- there would be no seeking when going between them.
    – jhfrontz
    Commented Feb 23, 2013 at 4:24
  • @jhfrontz, that could happen if the gap is small enough, but in practice, it is going to be many mb, which will be far enough that it won't be on the same cylinder.
    – psusi
    Commented Feb 23, 2013 at 18:30
  • I was thinking more like top and bottom sides of the same platter (no seek when going between).
    – jhfrontz
    Commented Feb 25, 2013 at 17:22
  • @jhfrontz, that is what it means to be on the same cylinder, just a different head.
    – psusi
    Commented Feb 25, 2013 at 18:10

You must log in to answer this question.

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