I still see lot of patches in release-3.7 are failing regression, be it
Linux or Netbsd. Does this mean all the spurious fixes which we did in
mainline are yet to be in 3.7? If so, what are we waiting for?
[1] has failed in glupy.t in netbsd which used to be the case 1 month
ago, but I thought it
- Original Message -
This seems to happen because of race between STACK_RESET and stack
statedump. Still thinking how to fix it without taking locks around
writing to file.
Why should we still keep the stack being reset as part of pending pool of
frames? Even we if we had to
This seems to happen because of race between STACK_RESET and stack
statedump. Still thinking how to fix it without taking locks around
writing to file.
Why should we still keep the stack being reset as part of pending pool of
frames? Even we if we had to (can't guess why?), when we remove we
On 06/05/2015 02:12 AM, Shyam wrote:
Just checking,
This review request: http://review.gluster.org/#/c/11073/
Failed in the following tests:
1) Linux
[20:20:16] ./tests/bugs/replicate/bug-880898.t ..
not ok 4
This seems to be same RC as in self-heald.t where heal info is not
failing
On 06/03/2015 07:29 PM, Csaba Henk wrote:
FYI -- efforts so far and perspectives as of my
understanding:
As noted, the Smart volume management group is a
singleton, but that single element is tricky. We
have heard promises of a glusterd rewrite that would
include the intelligence / structure
http://review.gluster.org/#/c/10967/ request is the one that has these
changes.
Doing a final review and merging the same.
Shyam
On 06/04/2015 12:22 PM, Kaleb KEITHLEY wrote:
Recent commits to xlators/cluster/dht/src/dht-common.c calls functions
which are not defined.
Was a file with
On 06/04/2015 12:26 PM, Shyam wrote:
http://review.gluster.org/#/c/10967/ request is the one that has these
changes.
This is now merged and the compile issue should be resolved.
Patches affected by this would need to be rebased.
(list that I see that have already failed)
-
Recent commits to xlators/cluster/dht/src/dht-common.c calls functions
which are not defined.
Was a file with dht_inode_ctx_get_mig_info() and
dht_mig_info_is_invalid() definitions omitted in a change set?
Right now the release-3.7 branch does not compile in jenkins smoke tests
and on
Requesting again. Can I get access to one of the slave machines so that
I can investigate the failure in volume-snapshot.t
Regards,
Avra
On 06/03/2015 12:30 PM, Avra Sengupta wrote:
+ Adding gluster-infra
On 06/03/2015 12:16 PM, Avra Sengupta wrote:
Hi,
Can I get access to one of the slave
On 06/03/2015 10:30 AM, Vijay Bellur wrote:
self-heald.t seems to fail intermittently.
One such instance was seen recently [1]. Can somebody look into this
please?
./tests/basic/afr/self-heald.t (Wstat: 0 Tests: 83 Failed: 1) Failed
test: 78
Thanks,
Vijay
I see that statedump is generating core because of which this test
spuriously fails. I am looking into it.
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
On 06/04/2015 11:44 AM, Avra Sengupta wrote:
Requesting again. Can I get access to one of the slave machines so that
I can investigate the failure in volume-snapshot.t
Hi Avra - I have reserved slave34 for your debugging. Please let us know
once done.
Thanks,
Vijay
On 06/04/2015 02:11 PM, Pranith Kumar Karampuri wrote:
hi Atin,
Could you help with this please:
http://build.gluster.org/job/rackspace-regression-2GB-triggered/10096/consoleFull
I see glusterd failed to start test 6 with the following reason:
[2015-06-04 04:23:34.669874] E [MSGID:
In a few moments, http://planet.gluster.org will show the release notes
for GlusterFS 3.5.4.
You can wait for the blog to catch up, or you can read the original post
here:
http://blog.nixpanic.net/2015/06/stable-releases-continue-glusterfs-354.html
Including the contents for the lazy people
Glustershd is crashing because afr wound xattrop with null gfid in loc.
Could one of you look into this failure?
http://build.gluster.org/job/rackspace-regression-2GB-triggered/10095/consoleFull
Pranith
___
Gluster-devel mailing list
This seems to happen because of race between STACK_RESET and stack
statedump. Still thinking how to fix it without taking locks around
writing to file.
Pranith
On 06/04/2015 02:13 PM, Pranith Kumar Karampuri wrote:
I see that statedump is generating core because of which this test
spuriously
This crash gives me a strange sense of deja vu. I remember seeing an invalid
(IA_INVAL) inode on which opendir() was being wound by SHD before.
Will take a look into this.
-Krutika
- Original Message -
From: Pranith Kumar Karampuri pkara...@redhat.com
To: Ravishankar N
17 matches
Mail list logo
