- Original Message -
> From: "Atin Mukherjee"
> To: "Vijay Bellur" , "Gluster Devel"
>
> Cc: "Vijaikumar Mallikarjuna" , "Sachin Pandit"
>
> Sent: Sunday, June 7, 2015 10:25:24 AM
> Subject: Re: [Gluster-devel] release-3.7 regression tests stability
>
>
>
> On 06/05/2015 11:38 PM,
Hi,
I just root-caused this issue. Am in the process of testing the fix. Will send
out the patch after that.
-Krutika
- Original Message -
> From: "Soumya Koduri"
> To: "Krutika Dhananjay" , "Pranith Kumar Karampuri"
>
> Cc: "Gluster Devel"
> Sent: Friday, June 5, 2015 4:54:44 PM
Hi Emmanuel,
Mind having a look @ [1] ?
All the tests are complaining about missing env.rc
[1]
http://build.gluster.org/job/rackspace-netbsd7-regression-triggered/6334/consoleFull
--
~Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http:
Currently I see Jenkin is not running/voting freebsd-smoke, netbsd-smoke
& devrpms checks. Have we disabled them? If yes why?
--
~Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
On 06/05/2015 04:01 PM, Anuradha Talur wrote:
> gluster volume heal info doesn't seem to fail because
> the process is crashing in afr_notify when invoked by glfs_fini.
> As a result proper error codes are not being propagated.
>
> Pranith had recently sent a patch : http://review.gluster.org/#
Here are some of the reasons why we are considering Go for
the next version of GlusterD.
- Existing C code already uses abstractions that come along
with Go, like coroutines, fan-out I/O minus the channels.
- Go promises lesser developement time than C.
- Go has bindings for consul/etcd APIs and
> Seems like we are already inside pool->lock while doing statedump which
> does writes to files, so may be I shouldn't think too much :-/. I will
> take a look at your patch once.
Ah, now it makes sense. I thought you knew about pool->lock already.
I was wondering why you were even trying to avoi
Emmanuel Dreyfus wrote:
> I will try to craft a change for that tomorrow.
Here it is:
http://review.gluster.org/4
This is untested, I rely on the test suite to find bugs.
While there, perhaps this one could be merged?
http://review.gluster.org/10747
--
Emmanuel Dreyfus
http://hcpnet.free
Parts of OpenStack Swift are also being re-written in Go, FYI.
http://lists.openstack.org/pipermail/openstack-dev/2015-April/063019.html
https://github.com/openstack/swift/tree/feature/hummingbird/go
Regards,
-Prashanth Pai
- Original Message -
> From: "Atin Mukherjee"
> To: "Justin Cl
Vijay Bellur wrote:
> I am also not certain why we end up with stale NFS mounts at the first
> place. Any ideas as to why this might be happening?
That happens when you try to umount while the NFS server is down, or in
our case after the NFS server process was shut down. The kernel waits in
unmo
Hi Manu,
I see that most NetBSD regressions are getting stuck in cleanup() due to
umount of a NFS export which hangs and never returns. Is there a way to
not let the scripts hang?
I already see that we are using umount -f which should perform a
forcible unmount of the filesystem.
I am also n
On 06/07/2015 05:40 PM, Pranith Kumar Karampuri wrote:
On 06/05/2015 09:10 AM, Krishnan Parthasarathi wrote:
- 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.
On 06/05/2015 09:10 AM, Krishnan Parthasarathi wrote:
- 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
On 06/05/2015 09:01 AM, Krishnan Parthasarathi wrote:
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 w
14 matches
Mail list logo
