<br><br><div class="gmail_quote">On Sun, Aug 19, 2012 at 6:18 AM, Emmanuel Dreyfus <span dir="ltr">&lt;<a href="mailto:manu@netbsd.org" target="_blank">manu@netbsd.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sun, Aug 19, 2012 at 05:52:56AM -0700, Anand Avati wrote:<br>
&gt; Oh BTW, did you add-brick from 1 brick to 2 bricks? If so it might be<br>
&gt; understandable as with 1 brick DHT is not loaded and there will be no hash<br>
&gt; ranges pre-assigned. If so can you try by starting with (volume create)<br>
&gt; with 2 bricks and then add-brick a 3rd one?<br>
<br>
</div>Yes, I went from 1 brick to 2 bricks. I will try 2-&gt;, but is 1-&gt;2 known<br>
to have issues?</blockquote><div><br></div><div>I now realize that if you re-refer an inode before it is timed out in the kernel (and LOOKUP is sent), then the code path hitting fuse_resolve_gfid_cbk might reach this. We need to call dht_self_heal in dht_discover_cbk if layout requires healing.</div>
<div><br></div><div>Avati</div></div>