<div dir="ltr">Venky,<div><br></div><div>Yes. You are right. We should not remove the quarantine entry in forget. </div><div><br></div><div>We have to remove it upon getting -ve lookups in bit-rot-stub and upon getting an unlink.</div><div><br></div><div>I have attached a patch for it. </div><div><br></div><div>Unfortunately rfc.sh is failing for me with the below error.</div><div><br></div><div><div><br></div><div>ssh: connect to host <a href="http://git.gluster.com">git.gluster.com</a> port 22: Connection timed out</div><div>fatal: Could not read from remote repository.</div><div><br></div><div>Please make sure you have the correct access rights</div><div>and the repository exists."</div></div><div><br></div><div><br></div><div>Regards,</div><div>Raghavendra</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 16, 2016 at 10:53 AM, Venky Shankar <span dir="ltr"><<a href="mailto:vshankar@redhat.com" target="_blank">vshankar@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Raghu,<br>
<br>
Bitrot stub inode forget implementation (br_stub_forget()) deletes the bad object<br>
marker (under quarantine directory) if present. This looks incorrect as ->forget()<br>
can be trigerred when inode table LRU size exceeeds configured limit - check bug<br>
#1308961 which tracks this issue. I recall that protocol/server calls inode_forget()<br>
on negative lookup (that might not invoke ->forget() though) and that's the reason<br>
why br_stub_forget() has this code.<br>
<br>
So, would it make sense to purge bad object marker just in lookup()? There might be<br>
a need to do the same in unlink() in case the object was removed by the client.<br>
<br>
Thoughts?<br>
<br>
Thanks,<br>
<br>
Venky<br>
</blockquote></div><br></div>