<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
Hi <span style="color:rgb(36, 36, 36);font-family:"Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif;font-size:14.6667px;background-color:rgb(255, 255, 255);display:inline !important" class="ContentPasted0">Zdenek,</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<span style="color:rgb(36, 36, 36);font-family:"Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif;font-size:14.6667px;background-color:rgb(255, 255, 255);display:inline !important" class="ContentPasted0"><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<span style="color:rgb(36, 36, 36);font-family:"Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif;font-size:14.6667px;background-color:rgb(255, 255, 255);display:inline !important" class="ContentPasted0">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.</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<span style="color:rgb(36, 36, 36);font-family:"Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif;font-size:14.6667px;background-color:rgb(255, 255, 255);display:inline !important" class="ContentPasted0"><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<span style="color:rgb(36, 36, 36);font-family:"Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif;font-size:14.6667px;background-color:rgb(255, 255, 255);display:inline !important" class="ContentPasted0">Regards,</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="elementToProof">
<span style="color:rgb(36, 36, 36);font-family:"Segoe UI", "Segoe UI Web (West European)", "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", sans-serif;font-size:14.6667px;background-color:rgb(255, 255, 255);display:inline !important" class="ContentPasted0">Pawan </span></div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Zdenek Kabelac <zdenek.kabelac@gmail.com><br>
<b>Sent:</b> Monday, October 17, 2022 6:40 PM<br>
<b>To:</b> Mitta Sai Chaithanya <mittas@microsoft.com>; LVM2 development <lvm-devel@redhat.com>; Pawan Sharma <sharmapawan@microsoft.com>; linux-lvm@redhat.com <linux-lvm@redhat.com><br>
<b>Cc:</b> Kapil Upadhayay <kupadhayay@microsoft.com><br>
<b>Subject:</b> Re: [EXTERNAL] Re: LVM2 : performance drop even after deleting the snapshot</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">[Some people who received this message don't often get email from zdenek.kabelac@gmail.com. Learn why this is important at
<a href="https://aka.ms/LearnAboutSenderIdentification">https://aka.ms/LearnAboutSenderIdentification</a> ]<br>
<br>
Dne 14. 10. 22 v 21:31 Mitta Sai Chaithanya napsal(a):<br>
> Hi Zdenek Kabelac,<br>
> Thanks for your quick reply and suggestions.<br>
><br>
> We conducted couple of tests on Ubuntu 22.04 and observed similar performance<br>
> behavior post thin snapshot deletion without writing any data anywhere.<br>
><br>
> *Commands used to create Thin LVM volume*:<br>
> - lvcreate -L 480G --poolmetadataspare n --poolmetadatasize 16G<br>
> --chunksize=64K --thinpool ThinDataLV ThinVolGrp<br>
> - lvcreate -n ext4.ThinLV -V 100G --thinpool ThinDataLV ThinVolGrp<br>
<br>
<br>
Hi<br>
<br>
So now it's clear you are talking about thin snapshots - this is a very<br>
different story going on here (as we normally use term "COW" volumes for thick<br>
old snapshots)<br>
<br>
I'll consult more with thinp author - however it does look to me you are using<br>
same device to store data & metadata.<br>
<br>
This is always a highly sub-optimal solution - the metadata device is likely<br>
best to be stored on fast (low latency) devices.<br>
<br>
So my wild guess - you are possibly using rotational device backend to store<br>
your thin-pools metadata volume and then your setups gets very sensitive on<br>
the metadata fragmentation.<br>
<br>
Thin-pool was designed to be used with SSD/NVMe for metadata which is way less<br>
sensitive on seeking.<br>
<br>
So when you 'create' snapshot - metadata gets updated - when you remove thin<br>
snapshot - metadata gets again a lots of changes (especially when your origin<br>
volume is already populated) - and fragmentation is inevitable and you are<br>
getting high penalty of holding metadata device on the same drive as your data<br>
device.<br>
<br>
So while there are some plans to improve some metadata logistic - I'd not<br>
expect miracles on you particular setup - I'd highly recommend to plug-in some<br>
SSD/NVMe storage for storing your thinpool metadata - this is the way to go<br>
to get better 'benchmarking' numbers here.<br>
<br>
For an improvement on your setup - try to seek larger chunk size values where<br>
your data 'sharing' is still reasonably valuable - this depends on data-type<br>
usage - but chunk size 256K might be possibly a good compromise (with disabled<br>
zeroing - if you hunt for the best performance).<br>
<br>
<br>
Regards<br>
<br>
Zdenek<br>
<br>
PS: later mails suggest you are using some 'MS Azure' devices?? - so please<br>
redo your testing with your local hardware/storage - where you have precise<br>
guarantees of storage drive performance - testing in the Cloud is random by<br>
design....<br>
<br>
</div>
</span></font></div>
</body>
</html>