+++ This bug was initially created as a clone of Bug #1436086 +++ Description of problem: In readdirp fop, op_errno is overloaded to indicate the EOD detection. If op_errno contains ENOENT, then it indicates that there are no further entries pending read in the directory. Currently NFS uses the ENOENT to identify the EOD. Issue: NFS clients issues a 4K buffer for readdirp, readdir-ahead converts it to 128K buffer as its reading ahead. If there are 100 entries in the bricks, 128K can get all 100 and store in readdir-ahead, but only 23 entries that can be fit in 4K will be sent to NFS. Since the whole 100 entries were read from brick, the op_errno is set to ENOENT, and the op_errno is propagated as is when sent to NFS. Hence NFS client in reading 23 entries thinks it reached EOD. Reproducer: Run the test case with parallel readdir on ./tests/bugs/distribute/bug-1190734.t Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: --- Additional comment from Worker Ant on 2017-03-27 02:39:19 EDT --- REVIEW: https://review.gluster.org/16953 (reddir-ahead: Fix EOD propagation problem) posted (#1) for review on master by Poornima G (pgurusid) --- Additional comment from Worker Ant on 2017-04-05 02:24:36 EDT --- COMMIT: https://review.gluster.org/16953 committed in master by Raghavendra G (rgowdapp) ------ commit 61f76f318faed395660f5bbcfe39616b39c158f0 Author: Poornima G <pgurusid> Date: Mon Mar 27 11:38:28 2017 +0530 reddir-ahead: Fix EOD propagation problem In readdirp fop, op_errno is overloaded to indicate the EOD detection. If op_errno contains ENOENT, then it indicates that there are no further entries pending read in the directory. Currently NFS uses the ENOENT to identify the EOD. Issue: NFS clients issues a 4K buffer for readdirp, readdir-ahead converts it to 128K buffer as its reading ahead. If there are 100 entries in the bricks, 128K can get all 100 and store in readdir-ahead, but only 23 entries that can be fit in 4K will be sent to NFS. Since the whole 100 entries were read from brick, the op_errno is set to ENOENT, and the op_errno is propagated as is when sent to NFS. Hence NFS client in reading 23 entries thinks it reached EOD. Solution: Do not propogate ENOENT errno, unless all the entries are read from the readdir ahead buffer. Change-Id: I4f173a77b21ab9e98ae35e291a45b8fc0cde65bd BUG: 1436086 Signed-off-by: Poornima G <pgurusid> Reviewed-on: https://review.gluster.org/16953 Smoke: Gluster Build System <jenkins.org> Reviewed-by: Raghavendra G <rgowdapp> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org>
REVIEW: https://review.gluster.org/17001 (reddir-ahead: Fix EOD propagation problem) posted (#1) for review on release-3.10 by Poornima G (pgurusid)
COMMIT: https://review.gluster.org/17001 committed in release-3.10 by Shyamsundar Ranganathan (srangana) ------ commit 5f95fbe05669bc6d262c425b40e1dba6f5f73f74 Author: Poornima G <pgurusid> Date: Mon Mar 27 11:38:28 2017 +0530 reddir-ahead: Fix EOD propagation problem In readdirp fop, op_errno is overloaded to indicate the EOD detection. If op_errno contains ENOENT, then it indicates that there are no further entries pending read in the directory. Currently NFS uses the ENOENT to identify the EOD. Issue: NFS clients issues a 4K buffer for readdirp, readdir-ahead converts it to 128K buffer as its reading ahead. If there are 100 entries in the bricks, 128K can get all 100 and store in readdir-ahead, but only 23 entries that can be fit in 4K will be sent to NFS. Since the whole 100 entries were read from brick, the op_errno is set to ENOENT, and the op_errno is propagated as is when sent to NFS. Hence NFS client in reading 23 entries thinks it reached EOD. Solution: Do not propogate ENOENT errno, unless all the entries are read from the readdir ahead buffer. > Reviewed-on: https://review.gluster.org/16953 > Smoke: Gluster Build System <jenkins.org> > Reviewed-by: Raghavendra G <rgowdapp> > NetBSD-regression: NetBSD Build System <jenkins.org> > CentOS-regression: Gluster Build System <jenkins.org> > (cherry picked from commit 61f76f318faed395660f5bbcfe39616b39c158f0) Change-Id: I4f173a77b21ab9e98ae35e291a45b8fc0cde65bd BUG: 1439148 Signed-off-by: Poornima G <pgurusid> Reviewed-on: https://review.gluster.org/17001 Smoke: Gluster Build System <jenkins.org> Reviewed-by: Raghavendra G <rgowdapp> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org>
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.10.2, please open a new bug report.