Red Hat Bugzilla – Bug 800833
ENOENT while deleting and creating the same file again
Last modified: 2012-04-27 00:02:19 EDT
Description of problem: On a single export volume with 2 fuse clients, the file created from one client 1 was deleted from client 2. When I tried creating the file with the same name again from Client 1, it returned ENOENT.
The md-cache timeout value was set to 30.
Version-Release number of selected component (if applicable): 3.3.0qa25
How reproducible: Consistently
Steps to Reproduce:
1. Client 1: echo 'abcd' > dot
2. Client 2: rm -rf dot
3. Client 1: echo 'abcd' > dot
[root@RHEL6 mnt]# echo 'abcd' > dot
-bash: dot: No such file or directory
[2012-03-07 00:18:13.534141] I [fuse-bridge.c:4089:fuse_graph_setup] 0-fuse: switched to graph 0
[2012-03-07 00:18:13.534383] I [fuse-bridge.c:3336:fuse_init] 0-glusterfs-fuse: FUSE inited with protocol versions: glusterfs 7.13 kernel 7.13
[2012-03-07 00:23:34.910871] W [client3_1-fops.c:375:client3_1_open_cbk] 0-dist-client-0: remote operation failed: No such file or directory. Path: /dot
[2012-03-07 00:23:34.910947] W [fuse-bridge.c:692:fuse_fd_cbk] 0-glusterfs-fuse: 78: OPEN() /dot => -1 (No such file or directory)
[2012-03-07 00:23:37.519608] W [client3_1-fops.c:375:client3_1_open_cbk] 0-dist-client-0: remote operation failed: No such file or directory. Path: /dot
[2012-03-07 00:23:37.519653] W [fuse-bridge.c:692:fuse_fd_cbk]
with non-zero timeouts, its expected that md-cache can go out of sync. In this case, lookup call is served from stale cache (cache rendered stale by unlink of file from another client) there by resulting in ENOENT errors. If some one wants zero tolerance towards stale-caches, they can use timeout value 0. Closing this bug, since its a known issue.
*** Bug 800822 has been marked as a duplicate of this bug. ***
Since we see this issue even when md-cache timeout is 0, reopening this bug.
This issue is not seen anymore.