[linux-lvm] Need inputs: Performance issues with LVM snapshots

Demi Marie Obenour demi at invisiblethingslab.com
Mon Mar 7 14:49:11 UTC 2022


On 3/7/22 09:44, Gionatan Danti wrote:
> Il 2022-03-07 12:09 Gaikwad, Hemant ha scritto:
>> Hi,
>>
>> We have been looking at LVM as an option for long term backup using
>> the LVM snapshots. After looking at the various forums and also
>> looking at a few LVM defects, realized that LVM could be a very good
>> option for short term backup, but might result in performance issues
>> if the snapshots are retained for a long time. Also read we should
>> restrict the number of snapshots. We are thinking of keeping it to 3,
>> but do you think that could also be a performance bottleneck. A few
>> forum posts also suggest memory issues with using LVM snapshots. Can
>> you please help with some data on that too. Thanks in advance for
>> making our decision easier. Thanks
>>
>> Regards,
> 
> Classical, non-thin LVM snapshots are only meant to be short-lived (just 
> enough to take a backup), and the performance penalty you talk about 
> does apply.
> Thin LVM snapshots, on the other side, command a much lower performance 
> penalty and can be long-lived (ie: think about a rolling snapshot 
> system).
> So if you need multiple, long-lived snapshots, I strongly suggest you to 
> check lvmthin.
> Regards.

Also worth noting that there is a minimum time to perform an LVM
operation of any type, a bit over 0.2 seconds on my machine.  If you
need to create snapshots exceedingly quickly, then LVM itself will be a
bottleneck.  Virtually all applications will not run into this problem,
however.  The only ones I can think of that will are container or VM
managers that need to spin up a lot of containers or VMs, as Qubes
OS does.  The time I mentioned is the time needed to run the entire LVM
command; the time I/O is suspended for is far, *far* shorter.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xB288B55FFF9C22C1.asc
Type: application/pgp-keys
Size: 4885 bytes
Desc: OpenPGP public key
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20220307/38453424/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20220307/38453424/attachment.sig>


More information about the linux-lvm mailing list