<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 12, 2017 at 10:37 PM, Kinglong Mee <span dir="ltr"><<a href="mailto:mijinlong@open-fs.com" target="_blank">mijinlong@open-fs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, this one is silly rename,<br>
<span class=""><br>
>>> rm: cannot remove ‘/mnt/nfs/ltp-JEYAuky2dz/.<wbr>nfsaa46457a6a72f8ea000014f5’: Device or resource busy<br>
<br>
</span>But, the other one isn't client's silly rename,<br>
<span class=""><br>
>>>> rm: cannot remove ‘/mnt/nfs/ltp-JEYAuky2dz/<wbr>rmderQsjV’: Directory not empty<br>
<br>
</span>Also, the second one often appears when testing ganesha nfs by ltp.<br>
<br>
I try to get an tcpdump, I found, when ls under the nfs client directory,<br>
<br>
the glusterfs client doesn't send readdir to glusterfs server, so that,<br>
the nfs client gets an empty directory information, but it's empty underlying.<br>
<br>
ls at some other directory,<br>
the glusterfs client send readdir to glusterfs server, nfs client gets right dirctory<br>
information as the underlying.<br>
<br>
So, I guess maybe there are some problems in MDCHANE or glusterfs client?<br>
<br>
]# cat /var/lib/glusterd/vols/gvtest/<wbr>trusted-gvtest.tcp-fuse.vol<br>
volume gvtest-client-0<br>
type protocol/client<br>
option send-gids true<br>
option password d80765c8-95ae-46ed-912a-<wbr>0c98fdd1e7cd<br>
option username 7bc6276f-245c-477a-99d0-<wbr>7ead4fcb2968<br>
option transport.address-family inet<br>
option transport-type tcp<br>
option remote-subvolume /gluster-test/gvtest<br>
option remote-host 192.168.9.111<br>
option ping-timeout 42<br>
end-volume<br>
<br>
volume gvtest-client-1<br>
type protocol/client<br>
option send-gids true<br>
option password d80765c8-95ae-46ed-912a-<wbr>0c98fdd1e7cd<br>
option username 7bc6276f-245c-477a-99d0-<wbr>7ead4fcb2968<br>
option transport.address-family inet<br>
option transport-type tcp<br>
option remote-subvolume /gluster-test/gvtest<br>
option remote-host 192.168.9.111<br>
option ping-timeout 42<br>
end-volume<br>
<br>
volume gvtest-dht<br>
type cluster/distribute<br>
option lock-migration off<br>
subvolumes gvtest-client-0 gvtest-client-1<br>
end-volume<br>
<br>
volume gvtest<br>
type debug/io-stats<br>
option count-fop-hits off<br>
option latency-measurement off<br>
option log-level INFO<br>
subvolumes gvtest-dht<br>
end-volume<br>
<br>
<br></blockquote><div><br></div><div><br></div><div>Have you checked the gluster export directories after receiving ENOTEMPTY? If you observe any files there, can you please check if they are 0-byte files with access mode 600 and sticky bit set? </div><div><br></div><div>When a file is being renamed, if the hash value of its new name happens to fall in a range that is different than that of the old name, gluster creates one such file. In the past we have seen instances of these files not being cleaned up properly in some cases and that causes a ENOTEMPTY when rmdir lands on the parent directory. Trying to see if we are hitting the same problem here.</div><div><br></div><div>Regards,</div><div>Vijay</div></div></div></div>