Re: [Gluster-devel] Running gfid-mismatch.t on NetBSD
Yes this is the expected behavior. Pranith On 07/03/2014 03:25 PM, Emmanuel Dreyfus wrote: Hi Running the first test on NetBSD, I get: = TEST 11 (line 22): ! find /mnt/glusterfs/0/file | xargs stat find: /mnt/glusterfs/0/file: Input/output error not ok 11 RESULT 11: 1 = Why is this failing? If I read correctly the test, we have set a gfid mismatch and find /mnt/glusterfs/0/file getting EIO is the expected behavior. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Running gfid-mismatch.t on NetBSD
Pranith Kumar Karampuri pkara...@redhat.com wrote: Yes this is the expected behavior. Then is the not ok 11 something I should see? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Running gfid-mismatch.t on NetBSD
On 07/03/2014 04:56 PM, Emmanuel Dreyfus wrote: Pranith Kumar Karampuri pkara...@redhat.com wrote: Yes this is the expected behavior. Then is the not ok 11 something I should see? Yes. See why it is succeeding instead of failing? Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [PATCH] fuse: ignore entry-timeout on LOOKUP_REVAL
On Fri, Jun 27, 2014 at 9:59 AM, Niels de Vos nde...@redhat.com wrote: On Thu, Jun 26, 2014 at 08:21:57PM -0400, Anand Avati wrote: The following test case demonstrates the bug: sh# mount -t glusterfs localhost:meta-test /mnt/one sh# mount -t glusterfs localhost:meta-test /mnt/two sh# echo stuff /mnt/one/file; rm -f /mnt/two/file; echo stuff /mnt/one/file bash: /mnt/one/file: Stale file handle sh# echo stuff /mnt/one/file; rm -f /mnt/two/file; sleep 1; echo stuff /mnt/one/file On the second open() on /mnt/one, FUSE would have used the old nodeid (file handle) trying to re-open it. Gluster is returning -ESTALE. The ESTALE propagates back to namei.c:filename_lookup() where lookup is re-attempted with LOOKUP_REVAL. The right behavior now, would be for FUSE to ignore the entry-timeout and and do the up-call revalidation. Instead FUSE is ignoring LOOKUP_REVAL, succeeding the revalidation (because entry-timeout has not passed), and open() is again retried on the old file handle and finally the ESTALE is going back to the application. Fix: if revalidation is happening with LOOKUP_REVAL, then ignore entry-timeout and always do the up-call. Signed-off-by: Anand Avati av...@redhat.com Looks good to me. Reviewed-by: Niels de Vos nde...@redhat.com Thanks, queued. Miklos ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Change in capturing coredumps during patch regression
Hi, One of the recent problems posted on gluster-devel regarding the ability to view coredumps that occur during regression testing for patch acceptance was discussed here [1]. Towards this, the core collection is now modified to collect system libraries that were used by the executable that cored, so as to facilitate debugging better. [2] To see the core in all its glory, please use the following method (this is echoed on the regression console as well, where the core URL is printed), - Download and extract the core tarball to any suitable location (for this discussion, say /home/user/cores/regressioncore) - cd to, the extracted directory (cd /home/user/cores/regressioncore) - You would now (usually) see the following directories here, build usr lib64 - Determine which core you want to open (assuming there are more than one) and which target it belongs to (like glusterd, glusterfsd etc.) - Open the core as, gdb -ex 'set sysroot ./' -ex 'core-file ./build/install/cores/core.xxx' path to target (say ./build/install/sbin/glusterd) The above should now display required symbol information and related data using the libraries from the regression machine and help debug the core better. As a cross check use 'info sharedlibrary' inside gdb to check if all shared libraries are available and loaded based on the sysroot set. An alternate to the above mechanism would be to simply launch gdb and go in series with the commands, 'set sysroot ./' - 'target exec target' - 'target core core'. Further enhancement for interested readers, - We can enhance the core collection to not package all of gluster libraries and executable, but just those that are involved in the crash, this can help reduce the size of the core tarball to a good extent (and extend its shelf life on the regression machines for examination). - The current bash script changes (in [2]) can be improved upon (for sure) by experienced bash script writers :) Shyam [1] http://supercolony.gluster.org/pipermail/gluster-devel/2014-June/041161.html [2] https://forge.gluster.org/gluster-patch-acceptance-tests/gluster-patch-acceptance-tests/commit/3e37d60bf34863a5e5b74f4cc551abf439244415 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] bug-822830.t fails on release-3.5 branch
Hi Niels/ Santosh, tests/bugs/bug-830665.t is consistently failing on 3.5 branch: not ok 17 Got *.redhat.com instead of \*.redhat.com not ok 19 Got 192.168.10.[1-5] instead of 192.168.10.\[1-5] and seems to be introduced by http://review.gluster.org/#/c/8223/ Could you please look into it? Thanks, Ravi ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] bug-822830.t fails on release-3.5 branch
On 07/04/2014 11:09 AM, Pranith Kumar Karampuri wrote: Ravi, I already sent a patch for it in the morning at http://review.gluster.com/8233 Review please :-) 830665.t is identical in master where it succeeds. Looks like *match_subnet_v4() changes in master need to be backported to 3.5 as well. Pranith On 07/04/2014 11:00 AM, Ravishankar N wrote: Hi Niels/ Santosh, tests/bugs/bug-830665.t is consistently failing on 3.5 branch: not ok 17 Got *.redhat.com instead of \*.redhat.com not ok 19 Got 192.168.10.[1-5] instead of 192.168.10.\[1-5] and seems to be introduced by http://review.gluster.org/#/c/8223/ Could you please look into it? Thanks, Ravi ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] bug-822830.t fails on release-3.5 branch
On 07/04/2014 11:19 AM, Ravishankar N wrote: On 07/04/2014 11:09 AM, Pranith Kumar Karampuri wrote: Ravi, I already sent a patch for it in the morning at http://review.gluster.com/8233 Review please :-) 830665.t is identical in master where it succeeds. Looks like *match_subnet_v4() changes in master need to be backported to 3.5 as well. That is because Avati's patch where EXPECT matches reg-ex is not present on release-3.5 commit 9a34ea6a0a95154013676cabf8528b2679fb36c4 Author: Anand Avati av...@redhat.com Date: Fri Jan 24 18:30:32 2014 -0800 tests: support regex in EXPECT constructs Instead of just strings, provide the ability to specify a regex of the pattern to expect Change-Id: I6ada978197dceecc28490a2a40de73a04ab9abcd Signed-off-by: Anand Avati av...@redhat.com Reviewed-on: http://review.gluster.org/6788 Reviewed-by: Pranith Kumar Karampuri pkara...@redhat.com Tested-by: Gluster Build System jenk...@build.gluster.com Shall we backport this? Pranith Pranith On 07/04/2014 11:00 AM, Ravishankar N wrote: Hi Niels/ Santosh, tests/bugs/bug-830665.t is consistently failing on 3.5 branch: not ok 17 Got *.redhat.com instead of \*.redhat.com not ok 19 Got 192.168.10.[1-5] instead of 192.168.10.\[1-5] and seems to be introduced by http://review.gluster.org/#/c/8223/ Could you please look into it? Thanks, Ravi ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] bug-822830.t fails on release-3.5 branch
On 07/04/2014 11:19 AM, Ravishankar N wrote: On 07/04/2014 11:09 AM, Pranith Kumar Karampuri wrote: Ravi, I already sent a patch for it in the morning at http://review.gluster.com/8233 Review please :-) 830665.t is identical in master where it succeeds. Looks like *match_subnet_v4() changes in master need to be backported to 3.5 as well. Sorry! I meant 822830.t Pranith On 07/04/2014 11:00 AM, Ravishankar N wrote: Hi Niels/ Santosh, tests/bugs/bug-830665.t is consistently failing on 3.5 branch: not ok 17 Got *.redhat.com instead of \*.redhat.com not ok 19 Got 192.168.10.[1-5] instead of 192.168.10.\[1-5] and seems to be introduced by http://review.gluster.org/#/c/8223/ Could you please look into it? Thanks, Ravi ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
