<div>Hi all,</div><div><br></div><div>First of all, I have sent a mail about FD leak in network failure before.</div><div> - <a href="http://supercolony.gluster.org/pipermail/gluster-devel/2014-August/041969.html">http://supercolony.gluster.org/pipermail/gluster-devel/2014-August/041969.html</a></div><div> &#39;About file descriptor leak in glusterfsd daemon after network failure&#39;</div><div><br></div><div>Thank Niels de Vos for telling me there is a bug 1129787 report and patch to solve.</div><div> - <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1129787">https://bugzilla.redhat.com/show_bug.cgi?id=1129787</a></div><div>And also I have applied the patch <a href="http://review.gluster.org/8065">http://review.gluster.org/8065</a> and set the </div><div>network.tcp-timeout as 30s to verify if the issue is fixed. </div><div><br></div><div>The patch and network.tcp-timeout setting worked fine mostly. However, I found </div><div>out that in a very subtle condition, the FD still leaked. Here is the details:</div><div><br></div><div>In a replicated gluster volume with 2 nodes server. On the client-side, I use </div><div>mount.glusterfs to access that gluster volume. I wrote a test program which </div><div>opened a file in the volume and flock it(only flock once), then read and write file </div><div>frequently. On one of nodes, I simulated a network failure for 15s then reconnect.</div><div>Note that the 15s is less than the network.tcp-timeout 30s, so the tcp connection is </div><div>kept alive. By this way, the FD of brick file will be leaked sometime. After the test </div><div>program exit, the FD in server-side wouldn&#39;t be closed. If restart the test program, </div><div>it will failed while flock, return a Resource Temporarily Unavailable error.</div><div><br></div><div>Network failure yimeline:</div><div>---(15s connected)---|---(15s disconnected)---|---(15s connected)---|...repeat...</div><div><br></div><div>To trace this issue, I added some log codes in xlators/storage/posix. Found that on </div><div>the network failure server, the glusterfsd will open and close file repeatedly in 1 </div><div>second when the network is connected(Is it a stat operation?). The leak FD happened </div><div>in the disconnection switch, the last opened fd isn&#39;t closed.</div><div><br></div><div>So would this kind of network frequent failure cause the message of closing fd lost?</div><div><br></div><div>And according to this issue, I find one patch.</div><div> - <a href="http://review.gluster.org/#/c/7470">http://review.gluster.org/#/c/7470</a></div><div>But I am not sure if this patch is the same with my situation.</div><div><br></div><div>My log:</div><div>(Connected logs)</div><div>[2014-09-09 12:05:49.055772] I [posix.c:1846:posix_open] 0-vs_vol_rep2-posix: real_path: /mnt/h1/testfile, _fd=18</div><div>[2014-09-09 12:05:49.058009] I [posix.c:2286:posix_release] 0-vs_vol_rep2-posix: posix_release: fd=18</div><div>[2014-09-09 12:05:49.058499] I [posix.c:1846:posix_open] 0-vs_vol_rep2-posix: real_path: /mnt/h1/testfile, _fd=18</div><div>[2014-09-09 12:05:49.060655] I [posix.c:2286:posix_release] 0-vs_vol_rep2-posix: posix_release: fd=18</div><div>[2014-09-09 12:05:49.061587] I [posix.c:1846:posix_open] 0-vs_vol_rep2-posix: real_path: /mnt/h1/testfile, _fd=18</div><div>...</div><div>// Disconnect for 15s, we can see that the fd=18 isn&#39;t closed.</div><div>...</div><div>[2014-09-09 12:06:15.910357] I [posix-helpers.c:1027:__posix_fd_ctx_get] 0-vs_vol_rep2-posix: open, _fd=16, real_path=/mnt/h1/.glusterfs/44/3d/443d50b8-5187-48d0-92ba-779c62cb9fe0</div><div>[2014-09-09 12:06:15.910637] I [posix.c:2286:posix_release] 0-vs_vol_rep2-posix: posix_release: fd=16</div><div>[2014-09-09 12:06:15.919489] I [posix-helpers.c:1027:__posix_fd_ctx_get] 0-vs_vol_rep2-posix: open, _fd=16, real_path=/mnt/h1/.glusterfs/44/3d/443d50b8-5187-48d0-92ba-779c62cb9fe0</div><div>[2014-09-09 12:06:15.919814] I [posix.c:2286:posix_release] 0-vs_vol_rep2-posix: posix_release: fd=16</div><div>[2014-09-09 12:06:16.003219] I [posix-helpers.c:1027:__posix_fd_ctx_get] 0-vs_vol_rep2-posix: open, _fd=16, real_path=/mnt/h1/.glusterfs/44/3d/443d50b8-5187-48d0-92ba-779c62cb9fe0</div><div>[2014-09-09 12:06:16.003395] I [posix.c:2286:posix_release] 0-vs_vol_rep2-posix: posix_release: fd=16</div><div>[2014-09-09 12:06:45.015708] I [posix.c:1846:posix_open] 0-vs_vol_rep2-posix: real_path: /mnt/h1/testfile, _fd=23</div><div><br></div><div>// On the server side, lsof show</div><div>#lsof /mnt/h1/testfile</div><div>COMMAND     PID USER   FD   TYPE DEVICE    SIZE/OFF      NODE NAME</div><div>glusterfs 10583 root   18u   REG   8,17 21478375424 335543947 /mnt/h1/testfile</div><div><br></div><div>// On the server-side, gluster volume status fd show</div><div># gluster volume status vol_rep2 h1:/mnt/h1 fd</div><div>FD tables for volume vs_vol_rep2</div><div>----------------------------------------------</div><div>Brick : vol_rep2 h1:/mnt/h1</div><div>Connection 1:</div><div>RefCount = 0  MaxFDs = 128  FirstFree = 2</div><div>FD Entry            PID                 RefCount            Flags              </div><div>--------            ---                 --------            -----              </div><div>0                   9153                1                   16386     </div><div> </div><div>Connection 2:</div><div>RefCount = 0  MaxFDs = 128  FirstFree = 0</div><div>No open fds</div><div> </div><div>// Note that 9153 is my test program pid which is EXITED already.</div><div><br></div><div>// statedump</div><div>[xlator.features.locks.vs_vol_rep2-locks.inode]</div><div>path=/testfile</div><div>mandatory=0</div><div>posixlk-count=1</div><div>posixlk.posixlk[0](ACTIVE)=type=WRITE, whence=0, start=0, len=0, pid = 9153, owner=dac8e118f3c2e02e, transport=0x7faba00090d0, , granted at Tue Sep  9 20:05:49 2014</div><div><br></div>