<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 29, 2016 at 12:37 PM, Kotresh Hiremath Ravishankar <span dir="ltr"><<a href="mailto:khiremat@redhat.com" target="_blank">khiremat@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Pranith,<br>
<br>
You had a concern of consuming I/O threads when bit-rot uses rchecksum interface to<br>
signing, normal scrubbing and on-demand scrubbing with tiering.<br>
<br>
<a href="http://review.gluster.org/#/c/13833/5/xlators/storage/posix/src/posix.c" rel="noreferrer" target="_blank">http://review.gluster.org/#/c/13833/5/xlators/storage/posix/src/posix.c</a><br>
<br>
As discussed over comments, the concern is valid and the above patch is not being<br>
taken in and would be abandoned.<br>
<br>
I have the following patch where the signing and normal scrubbing would not<br>
consume io-threads. Only the on-demand scrubbing consumes io-threads. I think<br>
this should be fine as tiering is single threaded and only consumes<br>
one I/O thread (as told by Joseph on PatchSet 6).<br>
<br>
<a href="http://review.gluster.org/#/c/13969/" rel="noreferrer" target="_blank">http://review.gluster.org/#/c/13969/</a></blockquote><div><br></div><div>I have a feeling that even this will become multi-threaded just like rebalance/self-heal have become. How do we future proof it?<br><br></div><div>Pranith<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Since, on-demand scrubbing is disabled by default and there is a size cap and<br>
we document to increase the default number of I/O threads, consuming one I/O<br>
thread for scrubbing would be fine I guess.<br>
<br>
Let me know your thoughts.<br>
<br>
Thanks and Regards,<br>
Kotresh H R<br>
<br>
</blockquote></div><br></div></div>