[linux-lvm] [EXTERNAL] Re: LVM2 : performance drop even after deleting the snapshot
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
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:
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...
More information about the linux-lvm