+++ This bug was initially created as a clone of Bug #1174783 +++ Description of problem: posix indicates EOF in readdir call by setting errno to ENOENT. But readdir-ahead is not doing it and is sending errno as 0. This causes problems when readdir-ahead is enabled along with USS and is accessed by windows. 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 Anand Avati on 2014-12-16 08:32:40 EST --- REVIEW: http://review.gluster.org/9283 (performance/readdir-ahead: indicate EOF for readdirp) posted (#1) for review on master by Raghavendra Bhat (raghavendra) --- Additional comment from Anand Avati on 2014-12-17 10:05:25 EST --- REVIEW: http://review.gluster.org/9283 (performance/readdir-ahead: indicate EOF for readdirp) posted (#2) for review on master by Raghavendra Bhat (raghavendra) --- Additional comment from Anand Avati on 2014-12-17 11:20:34 EST --- REVIEW: http://review.gluster.org/9283 (performance/readdir-ahead: indicate EOF for readdirp) posted (#3) for review on master by Raghavendra Bhat (raghavendra) --- Additional comment from Anand Avati on 2014-12-17 21:50:20 EST --- COMMIT: http://review.gluster.org/9283 committed in master by Vijay Bellur (vbellur) ------ commit cca09a2a342980f427b590f2655d23c371386a02 Author: Raghavendra Bhat <raghavendra> Date: Tue Dec 16 19:01:20 2014 +0530 performance/readdir-ahead: indicate EOF for readdirp posix xlator sends op_errno as ENOENT and op_ret as 0, to indicate readdir has been completed. readdir-ahead should send that op_errno that it has saved in the fd context, when it serves the readdir requests. Otherwise some xlators sitting above performance xlators such as snapview-client, which checks for end of readdir operation by checking op_ret to 0 and op_errno to ENOENT will not be able to identify end of readdir. Change-Id: Ib0835136c61cb1e0d7df933226c479c7db703a71 BUG: 1174783 Signed-off-by: Raghavendra Bhat <raghavendra> Reviewed-on: http://review.gluster.org/9283 Reviewed-by: Raghavendra G <rgowdapp> Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Brian Foster <bfoster> Reviewed-by: Vijay Bellur <vbellur>
REVIEW: http://review.gluster.org/9348 (performance/readdir-ahead: indicate EOF for readdirp) posted (#1) for review on release-3.6 by Sachin Pandit (spandit)
REVIEW: http://review.gluster.org/9348 (performance/readdir-ahead: indicate EOF for readdirp.) posted (#2) for review on release-3.6 by Sachin Pandit (spandit)
COMMIT: http://review.gluster.org/9348 committed in release-3.6 by Raghavendra Bhat (raghavendra) ------ commit 419015d5f61c9d9dcd93f9dda3f7b66f735ded83 Author: Raghavendra Bhat <raghavendra> Date: Tue Dec 16 19:01:20 2014 +0530 performance/readdir-ahead: indicate EOF for readdirp. posix xlator sends op_errno as ENOENT and op_ret as 0, to indicate readdir has been completed. readdir-ahead should send that op_errno that it has saved in the fd context, when it serves the readdir requests. Otherwise some xlators sitting above performance xlators such as snapview-client, which checks for end of readdir operation by checking op_ret to 0 and op_errno to ENOENT will not be able to identify end of readdir. Change-Id: Ib0835136c61cb1e0d7df933226c479c7db703a71 BUG: 1175753 Signed-off-by: Raghavendra Bhat <raghavendra> Reviewed-on: http://review.gluster.org/9283 Reviewed-by: Raghavendra G <rgowdapp> Tested-by: Gluster Build System <jenkins.com> Reviewed-by: Brian Foster <bfoster> Reviewed-by: Vijay Bellur <vbellur> Signed-off-by: Sachin Pandit <spandit> Reviewed-on: http://review.gluster.org/9348
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.6.2, please reopen this bug report. glusterfs-3.6.2 has been announced on the Gluster Developers mailinglist [1], packages for several distributions should already be or become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. The fix for this bug likely to be included in all future GlusterFS releases i.e. release > 3.6.2. [1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/5978 [2] http://news.gmane.org/gmane.comp.file-systems.gluster.user [3] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/6137