We just started using LVM on our raid array and feel it is slowing down the snapshot reversal operation that we use to test upgrades. We are not very familiar with this whole Raid and LVM thing so maybe it isn't possible.

So right now, we create a snapshot by doing:

  • lvcreate -l 100%FREE -n data_snap -s data/data
  • then we run our system upgrade package
  • lvconvert --merge 'data/data_snap'

It actually takes a long.... long.... long time to revert so the gain in efficiency is marginal right now. I believe this might be cause by a few problems but i'm trying to see how i can fix a few of those using this question:

  • We have the snapshot volume on the same physical disk as the original volume
  • We have an active software raid supporting all that in the back that RAID1's on 2 devices SDB and SDC that forms MD0
  • Our original setup takes 100% of MD0 to create /storage and we have no space to create the snapshot, so i also have to lvreduce my data/data to make some space and restore it to 100%VG once the snapshot is merged back
  • We moved /var to this RAID array on our initial setup, so i have to move it out to SDA and spoof bindings from MD0's /storage mount to SDA's /var, so we keep our docker stuff on the RAID to limit the changes to the volumes

So my options seem to be to find a way to suspend replication of SDB to SDC through MD0. But i have no clue how to do this. It will probably save me a LOT of trouble but i can't be sure.

Can anyone enlighten me?

  • 2
    If you need lots of snapshots and performance you probably should be looking for alternatives like zfs or btrfs. – Zoredache Jul 27 '17 at 21:14
  • @Zoredache It's not really a lot, it's more a reversion mechanism so we can easily test our changes. I would almost like it better that the snapshot itself (the changed data) is the one dropped so i can easily drop and restart. And once i'm in a production environment, having the old data in the snapshot dropped to commit fast would be an interresting feature! – Mathieu Dumoulin Jul 31 '17 at 12:28

Rather than abusing MD for this, you might consider using thin LVM pools for your snapshots.

Thick LVM snapshots (that is, what you're doing), don't work very well. They get very slow after only one layer of snapshots, and take a long time to merge, just as you're seeing. You're also running into problems of allocating an entire VG to a single LV that must first be shrunk before snapshot, which is super inefficient.

With a thin LVM pool, you can make thin logical volumes that are able to be allocated beyond 100%, allowing you to easily create snapshots if not all blocks are allocated to actual data. However, you should probably leave a percentage of your free physical extents for snapshots even in a thin pool configuration if you're using this in production. Your call.

Creating these thin volumes is only a few more steps than creating thick logical volumes. In fact, thin pools are actually just some additional metadata nested into a logical volume as you already have in your stack.

The following guide will help you in creating these volumes: Creating Thin Logical Volumes

And this will help you in creating snapshots of those volumes: Creating Thin Volume Snapshots

  • 1
    "With a thin LVM pool, you can make thin logical volumes that are able to be allocated beyond 100%" -- you should absolutely avoid to completely fill the thin pool (both writing to the "real" thin volumes or to their snapshots) or you will lose data. So thin lvm should be deployed only with robust monitoring or in a manner which make very difficult to fill the main pool. Anyway, +1 for identifying the best solution available on Linux at the moment. – shodanshok Jul 27 '17 at 21:03
  • How will a thin LVM pool change the performance of merging back the data? Aren't thinpools just a way to virtually over allocate? What i'd need is a way to make snapshots contain the changes instead of the replaced data. This way, dropping the snapshot would revert instantly! – Mathieu Dumoulin Jul 31 '17 at 12:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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