Re: [Gluster-devel] Want more spurious regression failure alerts... ?
One more spurious failure. ./tests/bugs/bug-1038598.t (Wstat: 0 Tests: 28 Failed: 1) Failed test: 28 Files=237, Tests=4632, 4619 wallclock secs ( 2.13 usr 1.48 sys + 832.41 cusr 697.97 csys = 1533.99 CPU) Result: FAIL Patch : http://review.gluster.org/#/c/8060/ Build URL : http://build.gluster.org/job/rackspace-regression-2GB/186/consoleFull ~ Sachin. - Original Message - From: Justin Clift jus...@gluster.org To: Pranith Kumar Karampuri pkara...@redhat.com Cc: Gluster Devel gluster-devel@gluster.org Sent: Sunday, June 15, 2014 3:55:05 PM Subject: Re: [Gluster-devel] Want more spurious regression failure alerts... ? On 15/06/2014, at 3:36 AM, Pranith Kumar Karampuri wrote: On 06/13/2014 06:41 PM, Justin Clift wrote: Hi Pranith, Do you want me to keep sending you spurious regression failure notification? There's a fair few of them isn't there? I am doing one run on my VM. I will get back with the ones that fail on my VM. You can also do the same on your machine. Cool, that should help. :) These are the spurious failures found when running the rackspace-regression-2G tests over friday and yesterday: * bug-859581.t -- SPURIOUS * 4846 - http://slave24.cloud.gluster.org/logs/glusterfs-logs-20140614:14:33:41.tgz * 6009 - http://slave20.cloud.gluster.org/logs/glusterfs-logs-20140613:20:24:58.tgz * 6652 - http://slave22.cloud.gluster.org/logs/glusterfs-logs-20140613:22:04:16.tgz * 7796 - http://slave20.cloud.gluster.org/logs/glusterfs-logs-20140614:14:22:53.tgz * 7987 - http://slave22.cloud.gluster.org/logs/glusterfs-logs-20140613:15:21:04.tgz * 7992 - http://slave10.cloud.gluster.org/logs/glusterfs-logs-20140613:20:21:15.tgz * 8014 - http://slave24.cloud.gluster.org/logs/glusterfs-logs-20140613:20:39:01.tgz * 8054 - http://slave24.cloud.gluster.org/logs/glusterfs-logs-20140613:13:15:50.tgz * 8062 - http://slave10.cloud.gluster.org/logs/glusterfs-logs-20140613:13:28:48.tgz * mgmt_v3-locks.t -- SPURIOUS * 6483 - build.gluster.org - http://build.gluster.org/job/regression/4847/consoleFull * 6630 - http://slave22.cloud.gluster.org/logs/glusterfs-logs-20140614:15:42:39.tgz * 6946 - http://slave21.cloud.gluster.org/logs/glusterfs-logs-20140613:20:57:27.tgz * 7392 - http://slave21.cloud.gluster.org/logs/glusterfs-logs-20140613:13:57:20.tgz * 7852 - http://slave24.cloud.gluster.org/logs/glusterfs-logs-20140613:19:23:17.tgz * 8014 - http://slave24.cloud.gluster.org/logs/glusterfs-logs-20140613:20:39:01.tgz * 8015 - http://slave23.cloud.gluster.org/logs/glusterfs-logs-20140613:14:26:01.tgz * 8048 - http://slave24.cloud.gluster.org/logs/glusterfs-logs-20140613:18:13:07.tgz * bug-918437-sh-mtime.t -- SPURIOUS * 6459 - http://slave21.cloud.gluster.org/logs/glusterfs-logs-20140614:18:28:43.tgz * 7493 - http://slave22.cloud.gluster.org/logs/glusterfs-logs-20140613:10:30:16.tgz * 7987 - http://slave10.cloud.gluster.org/logs/glusterfs-logs-20140613:14:23:02.tgz * 7992 - http://slave10.cloud.gluster.org/logs/glusterfs-logs-20140613:20:21:15.tgz * fops-sanity.t -- SPURIOUS * 8014 - http://slave20.cloud.gluster.org/logs/glusterfs-logs-20140613:18:18:33.tgz * 8066 - http://slave20.cloud.gluster.org/logs/glusterfs-logs-20140614:21:35:57.tgz * bug-857330/xml.t - SPURIOUS * 7523 - logs may (?) be hard to parse due to other failure data for this CR in them * 8029 - http://slave23.cloud.gluster.org/logs/glusterfs-logs-20140613:16:46:03.tgz If we resolve these five, our regression testing should be a *lot* more predictable. :) Text file (attached to this email) has the bulk test results. Manually cut-n-pasted from browser to the text doc, so be wary of possible typos. ;) Give the output of for i in `cat problematic-ones.txt`; do echo $i $(git log $i | grep Author| tail -1); done Maybe we should make 1 BZ for the lot, and attach the logs to that BZ for later analysis? I am already using 1092850 for this. Good info. :) + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift ___ 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] 3.5.1-beta2 Problems with suid and sgid bits on directories
You maybe looking at the problem being fixed here, [1]. On a lookup attribute mismatch was not being healed across directories, and this patch attempts to address the same. Currently the version of the patch does not heal the S_ISUID and S_ISGID bits, which is work in progress (but easy enough to incorporate and test based on the patch at [1]). On a separate note, add-brick just adds a brick to the cluster, the lookup is where the heal (or creation of the directory across all sub volumes in DHT xlator) is being done. Shyam [1] http://review.gluster.org/#/c/6983/ - Original Message - From: Anders Blomdell anders.blomd...@control.lth.se To: Gluster Devel gluster-devel@gluster.org Sent: Tuesday, June 17, 2014 10:53:52 AM Subject: [Gluster-devel] 3.5.1-beta2 Problems with suid and sgid bits on directories -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 With a glusterfs-3.5.1-0.3.beta2.fc20.x86_64 with a reverted 3dc56cbd16b1074d7ca1a4fe4c5bf44400eb63ff (due to local lack of IPv4 addresses), I get weird behavior if I: 1. Create a directory with suid/sgid/sticky bit set (/mnt/gluster/test) 2. Make a subdirectory of #1 (/mnt/gluster/test/dir1) 3. Do an add-brick Before add-brick 755 /mnt/gluster 7775 /mnt/gluster/test 2755 /mnt/gluster/test/dir1 After add-brick 755 /mnt/gluster 1775 /mnt/gluster/test 755 /mnt/gluster/test/dir1 On the server it looks like this: 7775 /data/disk1/gluster/test 2755 /data/disk1/gluster/test/dir1 1775 /data/disk2/gluster/test 755 /data/disk2/gluster/test/dir1 Filed as bug: https://bugzilla.redhat.com/show_bug.cgi?id=1110262 If somebody can point me to where the logic of add-brick is placed, I can give it a shot (a find/grep on mkdir didn't immediately point me to the right place). Regards Anders Blomdell - -- Anders Blomdell Email: anders.blomd...@control.lth.se Department of Automatic Control Lund University Phone:+46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJToFZ/AAoJENZYyvaDG8NcIVgH/0FnyTuB/yutrAdKhOCFTGGY fKqWEozJjiUB4TE8hvAnYw7DalT6jlPLUre6vGzUuioS6TQNn8emTFA7GN9Ghklv pc2I8NWtwju2iXqLO5ACjBDRuFcYaDLQRVzBFiQpOoOkwrly0uEvcSgUKFxrSuMx NrUZKgYTjZb+8kwnSsFv/QNlcPR7zWAiyqbu7rh2a2Q9ArwEsLyTi+se6z/T3PIH ASEIR86jWywaP/JDRoSIUX0PIIS8v7mciFtCVGmgIHfugmEwDH2ZxQtbrkxHOC3/ UjOaGY0TYwPNRnlzk2qkk6Yo3bALGzHa4SUfdRf+gvNa0wZLQWFTdnhWP1dPMc0= =tMUX -END PGP SIGNATURE- ___ 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] 3.5.1-beta2 Problems with suid and sgid bits on directories
On 2014-06-17 17:49, Shyamsundar Ranganathan wrote: You maybe looking at the problem being fixed here, [1]. On a lookup attribute mismatch was not being healed across directories, and this patch attempts to address the same. Currently the version of the patch does not heal the S_ISUID and S_ISGID bits, which is work in progress (but easy enough to incorporate and test based on the patch at [1]). Thanks, will look into it tomorrow. On a separate note, add-brick just adds a brick to the cluster, the lookup is where the heal (or creation of the directory across all sub volumes in DHT xlator) is being done. Thanks for the clarification (I guess that a rebalance would trigger it as well?) Shyam [1] http://review.gluster.org/#/c/6983/ - Original Message - From: Anders Blomdell anders.blomd...@control.lth.se To: Gluster Devel gluster-devel@gluster.org Sent: Tuesday, June 17, 2014 10:53:52 AM Subject: [Gluster-devel] 3.5.1-beta2 Problems with suid and sgid bits ondirectories With a glusterfs-3.5.1-0.3.beta2.fc20.x86_64 with a reverted 3dc56cbd16b1074d7ca1a4fe4c5bf44400eb63ff (due to local lack of IPv4 addresses), I get weird behavior if I: 1. Create a directory with suid/sgid/sticky bit set (/mnt/gluster/test) 2. Make a subdirectory of #1 (/mnt/gluster/test/dir1) 3. Do an add-brick Before add-brick 755 /mnt/gluster 7775 /mnt/gluster/test 2755 /mnt/gluster/test/dir1 After add-brick 755 /mnt/gluster 1775 /mnt/gluster/test 755 /mnt/gluster/test/dir1 On the server it looks like this: 7775 /data/disk1/gluster/test 2755 /data/disk1/gluster/test/dir1 1775 /data/disk2/gluster/test 755 /data/disk2/gluster/test/dir1 Filed as bug: https://bugzilla.redhat.com/show_bug.cgi?id=1110262 If somebody can point me to where the logic of add-brick is placed, I can give it a shot (a find/grep on mkdir didn't immediately point me to the right place). /Anders -- Anders Blomdell Email: anders.blomd...@control.lth.se Department of Automatic Control Lund University Phone:+46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Spurious failure - ./tests/bugs/bug-859581.t
Pranith, Regression test mentioned in $SUBJECT failed (testcase : 14 16) Console log can be found at http://build.gluster.org/job/rackspace-regression-2GB/227/consoleFull My initial suspect is on HEAL_TIMEOUT (set to 60 seconds) where healing might not have been completed within this time frame and i.e. why EXPECT_WITHIN fails. I am not sure on what basis this HEAL_TIMEOUT's value was derived. Probably you would be the better to analyse it. Having a larger time out value might help here? Cheers, Atin ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Spurious failure - ./tests/bugs/bug-859581.t
On 06/18/2014 10:04 AM, Pranith Kumar Karampuri wrote: On 06/18/2014 09:39 AM, Atin Mukherjee wrote: Pranith, Regression test mentioned in $SUBJECT failed (testcase : 14 16) Console log can be found at http://build.gluster.org/job/rackspace-regression-2GB/227/consoleFull My initial suspect is on HEAL_TIMEOUT (set to 60 seconds) where healing might not have been completed within this time frame and i.e. why EXPECT_WITHIN fails. I am not sure on what basis this HEAL_TIMEOUT's value was derived. Probably you would be the better to analyse it. Having a larger time out value might help here? I don't think it is a spurious failure. There seems to be a bug in afr-v2. I will have to fix that. If its not a spurious failure why its not failing every time? Pranith Cheers, Atin ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Spurious failure - ./tests/bugs/bug-859581.t
On 06/18/2014 10:11 AM, Atin Mukherjee wrote: On 06/18/2014 10:04 AM, Pranith Kumar Karampuri wrote: On 06/18/2014 09:39 AM, Atin Mukherjee wrote: Pranith, Regression test mentioned in $SUBJECT failed (testcase : 14 16) Console log can be found at http://build.gluster.org/job/rackspace-regression-2GB/227/consoleFull My initial suspect is on HEAL_TIMEOUT (set to 60 seconds) where healing might not have been completed within this time frame and i.e. why EXPECT_WITHIN fails. I am not sure on what basis this HEAL_TIMEOUT's value was derived. Probably you would be the better to analyse it. Having a larger time out value might help here? I don't think it is a spurious failure. There seems to be a bug in afr-v2. I will have to fix that. If its not a spurious failure why its not failing every time? Depends on which subvolume afr picks in readdir. If it reads the one with the directory it will succeed. Otherwise it will fail. Pranith Pranith Cheers, Atin ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
