<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Oct 20, 2008 at 9:55 PM, Rommer <span dir="ltr">&lt;<a href="mailto:rommer@active.by">rommer@active.by</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Sun, 19 Oct 2008 09:12:26 +0530<br>
&quot;Basavanagowda Kanur&quot; &lt;<a href="mailto:gowda@zresearch.com">gowda@zresearch.com</a>&gt; wrote:<br>
<br>
</div><div class="Ih2E3d">&gt; Rommer,<br>
&gt; &nbsp; It is not a memory leak.<br>
&gt; &nbsp; pl_forget() is not called by protocol/server, pl_forget() is called<br>
&gt; by __inode_destroy() after inode-&gt;ref becomes 0 (zero).<br>
&gt;<br>
<br>
</div><div><div></div><div class="Wj3C7c">Thanks.<br>
One more question:<br>
server_open_resume() makes new fd by fd_create(), but server_open_cbk()<br>
in protocol/server-protocol.c does not fd_destroy(fd), if op_ret &lt; 0.<br>
Where fd is destroing if open() failed?</div></div></blockquote><div><br>fd_destroy() is not called by any translator directly. fd_destroy() is called when fd-&gt;ref = 0(zero).<br><br>yes, thanks for pointing out. fd was getting leaked if open()/create()/opendir() failed. it is fixed in glusterfs--mainline--3.0--patch-440<br>
<br></div></div><br clear="all">-- <br>gowda<br>
</div>