<div dir="ltr">Hi, <div><br></div><div>I had done some experiments with kernel 4.2.8 that I am using for production right now and kernel 4.4 with commit <span style="font-size:16px">3d5f6733 ("dm thin metadata: speed up discard of partially mapped volumes") for comparison.</span></div><div><span style="font-size:16px"><br></span></div><div><span style="font-size:16px">All the experiments below are performed with a dm-thin pool (512KB block size) which is built with a RAID 0 composed by two Intel 480GB SSDs as metadata device and a zero-target DM device as the data device. The machine is equipped with an Intel E3-1246 v3 CPU and 16GB ram. </span></div><div><span style="font-size:16px"><br></span></div><div>To discard all the mappings of a fully-mapped 10TB thin device with 512KB block size,</div><div>kernel 4.4 takes 6m57s </div><div>kernel 4.2.8 takes 6m49s</div><div><br></div><div>To delete a fully-mapped 10TB thin device, </div><div>kernel 4.4 takes 48s</div><div>kernel 4.2.8 takes 47s</div><div><br></div><div>In another experiment, I create an empty thin device and a fully-mapped 10TB thin device. Then, I start writing to the empty thin device sequentially with fio before deleting the fully-mapped thin device. It can be observed that the write requests get blocked for couple of seconds (47~48sec) until the deletion process finishes on both kernel 4.2.8 and kernel 4.4. If we discard all the mappings in parallel with fio instead of deleting the fully-mapped thin device, write requests will still be blocked until all discard requests finished. I think this is because that pool's deferred list is full of all those discard requests and thus having no spare computation resource for new write requests to the other thin device. The kworker thread of thinp cause 100% CPU utilisation while processing the discard requests.</div><div><br></div><div>Hope this information helps.</div><div><br></div><div>Thanks,</div><div>Dennis  </div><br style="font-size:16px"></div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-23 0:43 GMT+08:00 Joe Thornber <span dir="ltr"><<a href="mailto:thornber@redhat.com" target="_blank">thornber@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Jan 22, 2016 at 02:38:28PM +0100, Lars Ellenberg wrote:<br>
> We have seen lvremove of thin snapshots sometimes minutes,<br>
> even ~20 minutes before.<br>
<br>
</span>I did some work on speeding up thin removal in autumn '14, in<br>
particular agressively prefetching metadata pages sped up the tree<br>
traversal hugely.  Could you confirm you're seeing pauses of this<br>
duration with currently kernels please?<br>
<br>
Obviously any pause, even a few seconds is unacceptable.  Having a<br>
background kernel worker thread doing the delete, as you describe, is<br>
the way to go.  But there are complications to do with<br>
transactionality and crash protection that have prevented me<br>
implementing it.  I'll think on it some more now I know it's such a<br>
problem for you.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Joe<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
dm-devel mailing list<br>
<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><span lang="EN-US" style="font-size:10pt;font-family:Arial,sans-serif">Dennis Yang </span><span lang="EN-US" style="font-size:10pt;font-family:Arial,sans-serif"> </span><span lang="EN-US" style="font-size:10pt;font-family:Arial,sans-serif"><br>QNAP Systems, Inc.</span><div><span lang="EN-US" style="font-size:10pt;font-family:Arial,sans-serif">Skype: qnap.dennis.yang<br>Email:</span><span lang="EN-US" style="font-size:10pt;font-family:Arial,sans-serif"> <a href="mailto:dennisyang@qnap.com" target="_blank">dennisyang@qnap.com</a></span><div><span lang="EN-US" style="font-size:10pt;font-family:Arial,sans-serif">Tel:</span><span style="font-family:Arial,sans-serif;font-size:13.333333969116211px"> (+886)-2-2393-5152 ext. </span><span style="font-family:Arial,sans-serif;font-size:13.333333969116211px">15018</span><div><font face="Arial, sans-serif" size="2">Address: </font><span style="color:rgb(51,51,51);font-family:Verdana,Arial,Helvetica,sans-serif;font-size:12px;line-height:18.66666603088379px">13F., No.56, Sec. 1, Xinsheng S. Rd., Zhongzheng Dist., Taipei City, Taiwan</span></div></div></div></div></div>
</div>