Pranith,
The core's backtrace [1] is not 'analysable'. It doesn't show function names
and displays ()? for all the frames across all threads. It would be helpful
if we had the glusterd logs corresponding to cluster.rc setup. These logs
are missing too.
thanks,
Krish
[1] - glusterd core file
On 19/06/2014, at 11:07 AM, Justin Clift wrote:
On 19/06/2014, at 10:52 AM, Krishnan Parthasarathi wrote:
Pranith,
The core's backtrace [1] is not 'analysable'. It doesn't show function names
and displays ()? for all the frames across all threads. It would be helpful
if we had the glusterd
On 06/19/2014 06:14 PM, Justin Clift wrote:
On 19/06/2014, at 1:23 PM, Pranith Kumar Karampuri wrote:
hi,
I was told that Justin and I were given permission to mark a patch as
verified+1 when the tests that failed are spurious failures. I think this
process can be automated as well. I
On 2014-06-19 13:48, Susant Palai wrote:
Adding Susant
Unfortunately things don't go so well here, with --brick-log-level=DEBUG, I get
very
weird results (probably because the first brick is slower to respond while it's
printing debug info), I suspect I trigger some timing related bug.
I attach
On 06/19/2014 03:39 PM, Anders Blomdell wrote:
On 2014-06-19 13:48, Susant Palai wrote:
Adding Susant
Unfortunately things don't go so well here, with --brick-log-level=DEBUG, I get
very
weird results (probably because the first brick is slower to respond while it's
printing debug info), I
On Tue, Jun 17, 2014 at 7:54 PM, Benjamin Turner bennytu...@gmail.com
wrote:
Yup,
On Jun 17, 2014 7:45 PM, Justin Clift jus...@gluster.org wrote:
On 17/06/2014, at 11:33 PM, Benjamin Turner wrote:
Here are the tests that failed. Note that n0 is a generated wname,
name255 is a 255
On 19/06/2014, at 6:55 PM, Benjamin Turner wrote:
snip
I went through these a while back and removed anything that wasn't valid for
GlusterFS. This test was passing on 3.4.59 when it was released, i am
thinking it may have something to do with a sym link to the same directory bz
i found
