[linux-lvm] [EXTERNAL] Re: LVM2 : performance drop even after deleting the snapshot

Zdenek Kabelac zdenek.kabelac at gmail.com
Tue Oct 18 11:15:38 UTC 2022


Dne 18. 10. 22 v 5:33 Pawan Sharma napsal(a):
> Hi Zdenek,
> 
> I would like to highlight one point here is that we are creating and then 
> deleting the snapshot immediately without writing anything anywhere. In this 
> case, we are expecting the performance to go back to what it was before taking 
> the thin snapshot. Here we are not getting the original performance after 
> deleting the snapshot. Do you know any reason why that would be happening.

As explained in my previous post - with thin-provisioning - you are getting 
metadata updates for bTrees - thus there is no 'revert' to previous 'metadata 
state' - there is rolling update of bTrees which is by design 'seek 
unfriendly' - so for the performance hunting users the use of SSD/NVMe type 
storage for these metadata volumes is basically a must (and it's been designed 
for that).

The old 'thick' snapshot where you allocate explicit COW LV storage is going 
to give here your expected behavior - however you will (of course) loose all 
the benefits you get with thin-pools.

With thin-pool (as also mentioned in my previous post) - if you can't afford 
dedicated low-latency storage - you need to scale-up chunk size - so the 
amount of metadata updates is reduced together (lowering seeking). I'm afraid 
you can't expect much more in the near future.

FYI there is to be merged in the upcoming kernel this patch set:

https://listman.redhat.com/archives/dm-devel/2022-October/052367.html

which should also help a lot with multithreaded load on thin-pools

There is also some new metadata format being experimented with - but whether 
this will also tackle anything in the seek friendlier logic is hard to tell...

Regards

Zdenek



More information about the linux-lvm mailing list