<div dir="ltr">Hi Joe,<div class="gmail_extra"><br><div class="gmail_quote">2016-06-24 21:55 GMT+08:00 Edward 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">Hi Dennis,<br>
<span class=""><br>
On Tue, Jun 21, 2016 at 03:56:26PM +0800, Dennis Yang wrote:<br>
> So my question is, does dm-thin have any mechanism to eliminate the race<br>
> when<br>
> discarded block is reused right away by another device?<br>
<br>
</span>I'll try and recreate your scenario.  The transaction-manager will not<br>
reallocate a block that's been freed within a transaction so that we<br>
can always rollback.  So as long as there hasn't been a commit,<br>
reallocation shouldn't be possible.  This is what normally guards<br>
allocation, but in your case I think you may be onto something and we<br>
may have to hold onto the data cell until the passdown discards are<br>
complete.<br>
<br>
- Joe<br>
</blockquote></div><br>In my experience, this issue is pretty hard to reproduce solely by a thin-pool </div><div class="gmail_extra">which is built on top of a regular hard disk or RAID, since I rarely observe the </div><div class="gmail_extra">DISCARD and WRITE coming from different thin devices get reordered in the </div><div class="gmail_extra">lower level. In my system, the thin-pool is built on top of another device-mapper </div><div class="gmail_extra">device providing data tiering functionality which could delay the DISCARD </div><div class="gmail_extra">request a little bit and lead to a request reorder situation. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Based on the log I had, I suspect that there was metadata commit before another</div><div class="gmail_extra">thin device reused the discarded block while the DISCARD request was still being</div><div class="gmail_extra">processed by the lower level stacks. In this case, holding the data cell until the </div><div class="gmail_extra">passdown discards are complete seems to only protect the discarded block from</div><div class="gmail_extra">being reallocated by the same thin device which allocates the block in the first place,</div><div class="gmail_extra">because only those write I/Os that are going to the same device will be prisoned. </div><div class="gmail_extra"><br></div><div class="gmail_extra">In my opinion, I think maybe the to-be-discard block should only be freed after the</div><div class="gmail_extra">passdown discards have been complete. I had only written a patch in this way and </div><div class="gmail_extra">applied it on my site since last week, and the issue had not been seen on my site </div><div class="gmail_extra">for 72 hours. I am not very confident about whether this patch will cause any side</div><div class="gmail_extra">effect, I would be highly appreciated if you can share your concern with me.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for your reply,</div><div class="gmail_extra">Dennis   </div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">   </div><div class="gmail_extra"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="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></div>