Change-Id: I2d10f2be44f518f496427f257988f1858e888084 BUG: 3348 Reviewed-on: http://review.gluster.com/200 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Anand Avati <avati@gluster.com>
Change-Id: I3914467611e573cccee0d22df93920cf1b2eb79f BUG: 3348 Reviewed-on: http://review.gluster.com/182 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Anand Avati <avati@gluster.com>
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
Now the code has lived up to the glorious state of not relying on getting the FLUSH whenever a file is released. So we don't need to forge one in release for the cases when the kernel doesn't send it. Undo commits: - 155ffe5c - c50bc710 - b8779318 (partly, just release related parts) Signed-off-by: Csaba Henk <csaba@gluster.com> Signed-off-by: Anand V. Avati <avati@dev.gluster.com> BUG: 223 (flush not sent) URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=223
Signed-off-by: Vijay Bellur <vijay@gluster.com> Signed-off-by: Vijay Bellur <vijay@dev.gluster.com> BUG: 971 (dynamic volume management) URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=971
Signed-off-by: Pranith Kumar K <pranithk@gluster.com> Signed-off-by: Vijay Bellur <vijay@dev.gluster.com> BUG: 1388 () URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1388
..so that when EOF is reached on this fd, any further requests on the same inode do not get handled through this fd but result in a new fd being opened. Unbinding results in the fd getting deleted from the inode's fd list. Signed-off-by: Shehjar Tikoo <shehjart@gluster.com> Signed-off-by: Vijay Bellur <vijay@dev.gluster.com> BUG: 1619 (glusterfs nfs server crashed on dht+replica(2x2)) URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1619
Signed-off-by: Raghavendra G <raghavendra@gluster.com> Signed-off-by: Vijay Bellur <vijay@dev.gluster.com> BUG: 1059 (enhancements for getting statistics from performance translators) URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1059
Now fuse is fully complaint with DVM, as even if there is a fop request on inode belonging to old graph, it will be resolved corresponding to new graph and operations will be performed wrt. new graph, which makes DVM truely spontaneous. Signed-off-by: Amar Tumballi <amar@gluster.com> Signed-off-by: Anand V. Avati <avati@dev.gluster.com> BUG: 1240 (DVM: after graph change, inodes should resolve to new inode-table) URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1240
Signed-off-by: Anand V. Avati <avati@blackhole.gluster.com> Signed-off-by: Anand V. Avati <avati@dev.gluster.com> BUG: 971 (dynamic volume management) URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=971