summaryrefslogtreecommitdiffstats
path: root/libglusterfsclient
diff options
context:
space:
mode:
authorAnand Avati <avati@gluster.com>2010-11-15 05:34:00 +0000
committerAnand V. Avati <avati@dev.gluster.com>2010-11-15 04:03:50 -0800
commit78654d270cde028c5d7f9da29b2790b90c19e11f (patch)
tree9c19e7ad52a8e3f20e72315b14d6eb00e08dad33 /libglusterfsclient
parent7d48999c13b885d034528cfca61a8b63ade8a365 (diff)
nfs: opendir/closedir for every readdir
Revert "nfs3: Unref & unbind dir fd with inode lock on EOF" This reverts commit 4e6fb304ce41acbaf7c9ba67c06bf443e65082e8. The above commit (which unbinds fds at EOF) does not fix the original bug (1619) because a readdir from a second app could have already started before the readdir_cbk of the first app's readdir reaches NFS code. Hence the race still exists. Performing extra unrefs when EOF is received is not a reliable way of detecting that a client has performed a closedir (and to close the fd ourselves). Neither is interpreting a 0 cookies a new opendir. Clients can always use telldir/seekdir and hit EOFs twice. Due to the way NFS3 protocol is designed, it is just not possible for the server to reliably detect opendirs/closedirs performed by the client and map the corresponding readdirs to the same dir fd on the server side. The only reliable way of fixing this is to perform opendir/closedir at the cost of performance. Any optimization towards keeping dir fds open attempting to map them with application's opendir/closedir will either result in fd leaks or extra fd unrefs. Signed-off-by: Anand V. Avati <avati@blackhole.gluster.com> Signed-off-by: Anand V. Avati <avati@dev.gluster.com> BUG: 2061 (NFS server crashes in readdir_fstat_cbk due to extra fd unref) URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=2061
Diffstat (limited to 'libglusterfsclient')
0 files changed, 0 insertions, 0 deletions