Re: [Gluster-devel] afr_set_transaction_flock lead to bad perforance when write with multi-pthread or multi-process
Hi,
>>>Can you please try and disable eager-lock?
Eager-lock is disabled already, and from the source code below:
Arbiter and data FOP will trigger FLOCK the entire file, isn’t it ?
if ((priv->arbiter_count || local->transaction.eager_lock_on ||
priv->full_lock) &&
local->transaction.type == AFR_DATA_TRANSACTION) {
/*Lock entire file to avoid network split brains.*/
int_lock->flock.l_len = 0;
int_lock->flock.l_start = 0;
} else {
Best Regards,
George
From: Yaniv Kaul
Sent: Friday, August 10, 2018 1:37 AM
To: Lian, George (NSB - CN/Hangzhou)
Subject: Re: [Gluster-devel] afr_set_transaction_flock lead to bad perforance
when write with multi-pthread or multi-process
Can you please try and disable eager-lock?
Y.
On Thu, Aug 9, 2018, 8:01 PM Lian, George (NSB - CN/Hangzhou)
mailto:george.l...@nokia-sbell.com>> wrote:
Hi, Gluster expert,
When we setup replicate volume with info like the below:
Volume Name: test
Type: Replicate
Volume ID: 9373eba9-eb84-4618-a54c-f2837345daec
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x (2 + 1) = 3
Transport-type: tcp
Bricks:
Brick1: rcp:/trunk/brick/test1/sn0
Brick2: rcp:/trunk/brick/test1/sn1
Brick3: rcp:/trunk/brick/test1/sn2 (arbiter)
If we run a performance test which could write a same file with multi-pthread
in same time.(write different offset). The write performance drop a lots (about
60%-70% off to the volume which no arbiter)
And when we study the source code, there is a function
“afr_set_transaction_flock” in” afr-transaction.c”,
It will flock the entire file when arbiter_count is not zero, I suppose it is
the root cause lead to performance drop.
Now my question is:
1) Why flock the entire file when arbiter is set on? Could you please share
the detail why it will lead to split brain only to arbiter?
2) If it is the root cause, and it really will lead to split-brain if not
lock entire file, is there any solution to avoid performance drop for this
mulit-write case?
The following is attached source code for this function FYI:
--
int afr_set_transaction_flock (xlator_t *this, afr_local_t *local)
{
afr_internal_lock_t *int_lock = NULL;
afr_private_t *priv = NULL;
int_lock = &local->internal_lock;
priv = this->private;
if ((priv->arbiter_count || local->transaction.eager_lock_on ||
priv->full_lock) &&
local->transaction.type == AFR_DATA_TRANSACTION) {
/*Lock entire file to avoid network split brains.*/
int_lock->flock.l_len = 0;
int_lock->flock.l_start = 0;
} else {
int_lock->flock.l_len = local->transaction.len;
int_lock->flock.l_start = local->transaction.start;
}
int_lock->flock.l_type = F_WRLCK;
return 0;
}
Thanks & Best Regards,
George
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Gluster Outreachy
Hi all, *Gentle reminder!* The doc[1] for adding project ideas for Outreachy will be open for editing till August 20th. Please feel free to add your project ideas :). [1]: https://docs.google.com/document/d/16yKKDD2Dd6Ag0tssrdoFPojKsF16QI5-j7cUHcR5Pq4/edit?usp=sharing Thanks, Bhumika On Wed, Jul 4, 2018 at 4:51 PM, Bhumika Goyal wrote: > Hi all, > > Gnome has been working on an initiative known as Outreachy[1] since 2010. > Outreachy is a three months remote internship program. It aims to increase > the participation of women and members from under-represented groups in > open source. This program is held twice in a year. During the internship > period, interns contribute to a project under the guidance of one or more > mentors. > > For the next round(Dec 2018- March 2019) we are planning to apply projects > from Gluster. We would like you to propose projects ideas or/and come > forward as mentors/volunteers. > Please feel free to add project ideas in this doc[2]. The doc[2] will be > open for editing till July end. > > [1]: https://www.outreachy.org/ > [2]: https://docs.google.com/document/d/16yKKDD2Dd6Ag0tssrdoFPojK > sF16QI5-j7cUHcR5Pq4/edit?usp=sharing > > Outreachy timeline: > Pre-Application Period - Late August to early September > Application Period - Early September to mid-October > Internship Period - December to March > > Thanks, > Bhumika > ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Spurious smoke failure in build rpms
On Thu, Aug 9, 2018 at 4:19 PM Nigel Babu wrote: > Infra issue. Please file a bug. > https://bugzilla.redhat.com/show_bug.cgi?id=1614631 Thanks! > On Thu, Aug 9, 2018 at 3:57 PM Pranith Kumar Karampuri < > pkara...@redhat.com> wrote: > >> https://build.gluster.org/job/devrpm-el7/10441/console >> >> *10:12:42* Wrote: >> /home/jenkins/root/workspace/devrpm-el7/extras/LinuxRPM/rpmbuild/SRPMS/glusterfs-4.2dev-0.240.git4657137.el7.src.rpm*10:12:42* >> mv rpmbuild/SRPMS/* .*10:12:44* INFO: mock.py version 1.4.11 starting >> (python version = 2.7.5)...*10:12:44* Start: init plugins*10:12:44* INFO: >> selinux disabled*10:12:44* Finish: init plugins*10:12:44* Start: >> run*10:12:44* INFO: Start(glusterfs-4.2dev-0.240.git4657137.el7.src.rpm) >> Config(epel-7-x86_64)*10:12:44* Start: clean chroot*10:12:44* ERROR: >> Exception(glusterfs-4.2dev-0.240.git4657137.el7.src.rpm) >> Config(epel-7-x86_64) 0 minutes 0 seconds >> >> >> I am not sure why it is saying exception for the src.rpm and failing, >> does anyone know? >> >> >> -- >> Pranith >> ___ >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> https://lists.gluster.org/mailman/listinfo/gluster-devel > > > > -- > nigelb > -- Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] ./tests/basic/afr/metadata-self-heal.t core dumped
On Fri, Aug 10, 2018 at 11:21 AM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:
>
>
> On Fri, Aug 10, 2018 at 8:54 AM Raghavendra Gowdappa
> wrote:
>
>> All,
>>
>> Details can be found at:
>> https://build.gluster.org/job/centos7-regression/2190/console
>>
>> Process that core dumped: glfs_shdheal
>>
>> Note that the patch on which this regression failures is on readdir-ahead
>> which is not loaded in xlator graph of self heal daemon.
>>
>> From bt,
>>
>> *23:53:24* __FUNCTION__ = "syncop_getxattr"*23:53:24* #8
>> 0x7f5af8738aef in syncop_gfid_to_path_hard (itable=0x7f5ae401ce50,
>> subvol=0x7f5ae40079e0, gfid=0x7f5adc00b4e8 "", inode=0x0,
>> path_p=0x7f5acbffebe8, hard_resolve=false) at
>> /home/jenkins/root/workspace/centos7-regression/libglusterfs/src/syncop-utils.c:585*23:53:24*
>> ret = 0*23:53:24* path = 0x0*23:53:24* loc = {path
>> = 0x0, name = 0x0, inode = 0x7f5ac00028a8, parent = 0x0, gfid = '\000'
>> , pargfid = '\000' }*23:53:24*
>> xattr = 0x0*23:53:24* #9 0x7f5af8738c28 in syncop_gfid_to_path
>> (itable=0x7f5ae401ce50, subvol=0x7f5ae40079e0, gfid=0x7f5adc00b4e8 "",
>> path_p=0x7f5acbffebe8) at
>> /home/jenkins/root/workspace/centos7-regression/libglusterfs/src/syncop-utils.c:636*23:53:24*
>> No locals.
>> *23:53:24* #10 0x7f5aeaad65e1 in afr_shd_selfheal
>> (healer=0x7f5ae401d490, child=0, gfid=0x7f5adc00b4e8 "") at
>> /home/jenkins/root/workspace/centos7-regression/xlators/cluster/afr/src/afr-self-heald.c:331*23:53:24*
>> ret = 0*23:53:24* eh = 0x0*23:53:24* priv =
>> 0x7f5ae401c780*23:53:24* shd = 0x7f5ae401c8e8*23:53:24*
>> shd_event = 0x0*23:53:24* path = 0x0*23:53:24* subvol =
>> 0x7f5ae40079e0*23:53:24* this = 0x7f5ae400d540*23:53:24*
>> crawl_event = 0x7f5ae401d4a0*23:53:24* #11 0x7f5aeaad6de5 in
>> afr_shd_full_heal (subvol=0x7f5ae40079e0, entry=0x7f5adc00b440,
>> parent=0x7f5acbffee20, data=0x7f5ae401d490) at
>> /home/jenkins/root/workspace/centos7-regression/xlators/cluster/afr/src/afr-self-heald.c:541*23:53:24*
>> healer = 0x7f5ae401d490*23:53:24* this =
>> 0x7f5ae400d540*23:53:24* priv = 0x7f5ae401c780*23:53:24* #12
>> 0x7f5af8737b2f in syncop_ftw (subvol=0x7f5ae40079e0, loc=0x7f5acbffee20,
>> pid=-6, data=0x7f5ae401d490, fn=0x7f5aeaad6d40 ) at
>> /home/jenkins/root/workspace/centos7-regression/libglusterfs/src/syncop-utils.c:123*23:53:24*
>> child_loc = {path = 0x0, name = 0x0, inode = 0x0, parent = 0x0,
>> gfid = '\000' , pargfid = '\000' > times>}*23:53:24* fd = 0x7f5ac0001398
>>
>>
>> Assert for a non-null gfid failed in client_pre_getxattr_v2. From bt, it
>> looks like a NULL gfid was passed to afr_shd_full.
>>
>
> Most probably it is because of the change in gf_link_inode_from_dirent()
> in your patch. Why did you make that change? Wondering if we need to change
> afr/ec code accordingly.
>
Please hold on. I'll let you know whether changes in afr/ec are necessary.
I am thinking whether that change is really necessary.
>
>>
>> *23:53:24* __PRETTY_FUNCTION__ = "client_pre_getxattr_v2"*23:53:24*
>> #5 0x7f5aeada8f2a in client4_0_getxattr (frame=0x7f5ac0008198,
>> this=0x7f5ae40079e0, data=0x7f5acbffdcc0) at
>> /home/jenkins/root/workspace/centos7-regression/xlators/protocol/client/src/client-rpc-fops_v2.c:4287*23:53:24*
>> conf = 0x7f5ae40293e0*23:53:24* args =
>> 0x7f5acbffdcc0*23:53:24* req = {gfid = '\000' ,
>> namelen = 0, name = 0x0, xdata = {xdr_size = 0, count = 0, pairs =
>> {pairs_len = 0, pairs_val = 0x0}}}*23:53:24* dict = 0x0*23:53:24*
>> ret = 0*23:53:24* op_ret = -1*23:53:24* op_errno =
>> 116*23:53:24* local = 0x7f5ac00082a8*23:53:24* __FUNCTION__
>> = "client4_0_getxattr"*23:53:24* __PRETTY_FUNCTION__ =
>> "client4_0_getxattr"
>>
>>
>> regards,
>> Raghavendra
>>
>
>
> --
> Pranith
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] ./tests/basic/afr/metadata-self-heal.t core dumped
On Fri, Aug 10, 2018 at 8:54 AM Raghavendra Gowdappa
wrote:
> All,
>
> Details can be found at:
> https://build.gluster.org/job/centos7-regression/2190/console
>
> Process that core dumped: glfs_shdheal
>
> Note that the patch on which this regression failures is on readdir-ahead
> which is not loaded in xlator graph of self heal daemon.
>
> From bt,
>
> *23:53:24* __FUNCTION__ = "syncop_getxattr"*23:53:24* #8
> 0x7f5af8738aef in syncop_gfid_to_path_hard (itable=0x7f5ae401ce50,
> subvol=0x7f5ae40079e0, gfid=0x7f5adc00b4e8 "", inode=0x0,
> path_p=0x7f5acbffebe8, hard_resolve=false) at
> /home/jenkins/root/workspace/centos7-regression/libglusterfs/src/syncop-utils.c:585*23:53:24*
> ret = 0*23:53:24* path = 0x0*23:53:24* loc = {path =
> 0x0, name = 0x0, inode = 0x7f5ac00028a8, parent = 0x0, gfid = '\000' 15 times>, pargfid = '\000' }*23:53:24* xattr =
> 0x0*23:53:24* #9 0x7f5af8738c28 in syncop_gfid_to_path
> (itable=0x7f5ae401ce50, subvol=0x7f5ae40079e0, gfid=0x7f5adc00b4e8 "",
> path_p=0x7f5acbffebe8) at
> /home/jenkins/root/workspace/centos7-regression/libglusterfs/src/syncop-utils.c:636*23:53:24*
> No locals.
> *23:53:24* #10 0x7f5aeaad65e1 in afr_shd_selfheal (healer=0x7f5ae401d490,
> child=0, gfid=0x7f5adc00b4e8 "") at
> /home/jenkins/root/workspace/centos7-regression/xlators/cluster/afr/src/afr-self-heald.c:331*23:53:24*
> ret = 0*23:53:24* eh = 0x0*23:53:24* priv =
> 0x7f5ae401c780*23:53:24* shd = 0x7f5ae401c8e8*23:53:24*
> shd_event = 0x0*23:53:24* path = 0x0*23:53:24* subvol =
> 0x7f5ae40079e0*23:53:24* this = 0x7f5ae400d540*23:53:24*
> crawl_event = 0x7f5ae401d4a0*23:53:24* #11 0x7f5aeaad6de5 in
> afr_shd_full_heal (subvol=0x7f5ae40079e0, entry=0x7f5adc00b440,
> parent=0x7f5acbffee20, data=0x7f5ae401d490) at
> /home/jenkins/root/workspace/centos7-regression/xlators/cluster/afr/src/afr-self-heald.c:541*23:53:24*
> healer = 0x7f5ae401d490*23:53:24* this =
> 0x7f5ae400d540*23:53:24* priv = 0x7f5ae401c780*23:53:24* #12
> 0x7f5af8737b2f in syncop_ftw (subvol=0x7f5ae40079e0, loc=0x7f5acbffee20,
> pid=-6, data=0x7f5ae401d490, fn=0x7f5aeaad6d40 ) at
> /home/jenkins/root/workspace/centos7-regression/libglusterfs/src/syncop-utils.c:123*23:53:24*
> child_loc = {path = 0x0, name = 0x0, inode = 0x0, parent = 0x0, gfid
> = '\000' , pargfid = '\000' }*23:53:24*
> fd = 0x7f5ac0001398
>
>
> Assert for a non-null gfid failed in client_pre_getxattr_v2. From bt, it
> looks like a NULL gfid was passed to afr_shd_full.
>
Most probably it is because of the change in gf_link_inode_from_dirent() in
your patch. Why did you make that change? Wondering if we need to change
afr/ec code accordingly.
>
> *23:53:24* __PRETTY_FUNCTION__ = "client_pre_getxattr_v2"*23:53:24*
> #5 0x7f5aeada8f2a in client4_0_getxattr (frame=0x7f5ac0008198,
> this=0x7f5ae40079e0, data=0x7f5acbffdcc0) at
> /home/jenkins/root/workspace/centos7-regression/xlators/protocol/client/src/client-rpc-fops_v2.c:4287*23:53:24*
> conf = 0x7f5ae40293e0*23:53:24* args =
> 0x7f5acbffdcc0*23:53:24* req = {gfid = '\000' ,
> namelen = 0, name = 0x0, xdata = {xdr_size = 0, count = 0, pairs = {pairs_len
> = 0, pairs_val = 0x0}}}*23:53:24* dict = 0x0*23:53:24* ret =
> 0*23:53:24* op_ret = -1*23:53:24* op_errno = 116*23:53:24*
> local = 0x7f5ac00082a8*23:53:24* __FUNCTION__ =
> "client4_0_getxattr"*23:53:24* __PRETTY_FUNCTION__ =
> "client4_0_getxattr"
>
>
> regards,
> Raghavendra
>
--
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] ./tests/basic/afr/metadata-self-heal.t core dumped
This looks to be from the code change
https://review.gluster.org/#/c/glusterfs/+/20639/4/libglusterfs/src/gf-dirent.c
I've reverted the changes and retriggered tests. Sorry about the confusion.
On Fri, Aug 10, 2018 at 8:54 AM, Raghavendra Gowdappa
wrote:
> All,
>
> Details can be found at:
> https://build.gluster.org/job/centos7-regression/2190/console
>
> Process that core dumped: glfs_shdheal
>
> Note that the patch on which this regression failures is on readdir-ahead
> which is not loaded in xlator graph of self heal daemon.
>
> From bt,
>
> *23:53:24* __FUNCTION__ = "syncop_getxattr"*23:53:24* #8
> 0x7f5af8738aef in syncop_gfid_to_path_hard (itable=0x7f5ae401ce50,
> subvol=0x7f5ae40079e0, gfid=0x7f5adc00b4e8 "", inode=0x0,
> path_p=0x7f5acbffebe8, hard_resolve=false) at
> /home/jenkins/root/workspace/centos7-regression/libglusterfs/src/syncop-utils.c:585*23:53:24*
> ret = 0*23:53:24* path = 0x0*23:53:24* loc = {path =
> 0x0, name = 0x0, inode = 0x7f5ac00028a8, parent = 0x0, gfid = '\000' 15 times>, pargfid = '\000' }*23:53:24* xattr =
> 0x0*23:53:24* #9 0x7f5af8738c28 in syncop_gfid_to_path
> (itable=0x7f5ae401ce50, subvol=0x7f5ae40079e0, gfid=0x7f5adc00b4e8 "",
> path_p=0x7f5acbffebe8) at
> /home/jenkins/root/workspace/centos7-regression/libglusterfs/src/syncop-utils.c:636*23:53:24*
> No locals.
> *23:53:24* #10 0x7f5aeaad65e1 in afr_shd_selfheal (healer=0x7f5ae401d490,
> child=0, gfid=0x7f5adc00b4e8 "") at
> /home/jenkins/root/workspace/centos7-regression/xlators/cluster/afr/src/afr-self-heald.c:331*23:53:24*
> ret = 0*23:53:24* eh = 0x0*23:53:24* priv =
> 0x7f5ae401c780*23:53:24* shd = 0x7f5ae401c8e8*23:53:24*
> shd_event = 0x0*23:53:24* path = 0x0*23:53:24* subvol =
> 0x7f5ae40079e0*23:53:24* this = 0x7f5ae400d540*23:53:24*
> crawl_event = 0x7f5ae401d4a0*23:53:24* #11 0x7f5aeaad6de5 in
> afr_shd_full_heal (subvol=0x7f5ae40079e0, entry=0x7f5adc00b440,
> parent=0x7f5acbffee20, data=0x7f5ae401d490) at
> /home/jenkins/root/workspace/centos7-regression/xlators/cluster/afr/src/afr-self-heald.c:541*23:53:24*
> healer = 0x7f5ae401d490*23:53:24* this =
> 0x7f5ae400d540*23:53:24* priv = 0x7f5ae401c780*23:53:24* #12
> 0x7f5af8737b2f in syncop_ftw (subvol=0x7f5ae40079e0, loc=0x7f5acbffee20,
> pid=-6, data=0x7f5ae401d490, fn=0x7f5aeaad6d40 ) at
> /home/jenkins/root/workspace/centos7-regression/libglusterfs/src/syncop-utils.c:123*23:53:24*
> child_loc = {path = 0x0, name = 0x0, inode = 0x0, parent = 0x0, gfid
> = '\000' , pargfid = '\000' }*23:53:24*
> fd = 0x7f5ac0001398
>
>
> Assert for a non-null gfid failed in client_pre_getxattr_v2. From bt, it
> looks like a NULL gfid was passed to afr_shd_full.
>
> *23:53:24* __PRETTY_FUNCTION__ = "client_pre_getxattr_v2"*23:53:24*
> #5 0x7f5aeada8f2a in client4_0_getxattr (frame=0x7f5ac0008198,
> this=0x7f5ae40079e0, data=0x7f5acbffdcc0) at
> /home/jenkins/root/workspace/centos7-regression/xlators/protocol/client/src/client-rpc-fops_v2.c:4287*23:53:24*
> conf = 0x7f5ae40293e0*23:53:24* args =
> 0x7f5acbffdcc0*23:53:24* req = {gfid = '\000' ,
> namelen = 0, name = 0x0, xdata = {xdr_size = 0, count = 0, pairs = {pairs_len
> = 0, pairs_val = 0x0}}}*23:53:24* dict = 0x0*23:53:24* ret =
> 0*23:53:24* op_ret = -1*23:53:24* op_errno = 116*23:53:24*
> local = 0x7f5ac00082a8*23:53:24* __FUNCTION__ =
> "client4_0_getxattr"*23:53:24* __PRETTY_FUNCTION__ =
> "client4_0_getxattr"
>
>
> regards,
> Raghavendra
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] ./tests/basic/afr/metadata-self-heal.t core dumped
All,
Details can be found at:
https://build.gluster.org/job/centos7-regression/2190/console
Process that core dumped: glfs_shdheal
Note that the patch on which this regression failures is on readdir-ahead
which is not loaded in xlator graph of self heal daemon.
>From bt,
*23:53:24* __FUNCTION__ = "syncop_getxattr"*23:53:24* #8
0x7f5af8738aef in syncop_gfid_to_path_hard (itable=0x7f5ae401ce50,
subvol=0x7f5ae40079e0, gfid=0x7f5adc00b4e8 "", inode=0x0,
path_p=0x7f5acbffebe8, hard_resolve=false) at
/home/jenkins/root/workspace/centos7-regression/libglusterfs/src/syncop-utils.c:585*23:53:24*
ret = 0*23:53:24* path = 0x0*23:53:24* loc =
{path = 0x0, name = 0x0, inode = 0x7f5ac00028a8, parent = 0x0, gfid =
'\000' , pargfid = '\000' }*23:53:24* xattr = 0x0*23:53:24* #9 0x7f5af8738c28
in syncop_gfid_to_path (itable=0x7f5ae401ce50, subvol=0x7f5ae40079e0,
gfid=0x7f5adc00b4e8 "", path_p=0x7f5acbffebe8) at
/home/jenkins/root/workspace/centos7-regression/libglusterfs/src/syncop-utils.c:636*23:53:24*
No locals.
*23:53:24* #10 0x7f5aeaad65e1 in afr_shd_selfheal
(healer=0x7f5ae401d490, child=0, gfid=0x7f5adc00b4e8 "") at
/home/jenkins/root/workspace/centos7-regression/xlators/cluster/afr/src/afr-self-heald.c:331*23:53:24*
ret = 0*23:53:24* eh = 0x0*23:53:24* priv =
0x7f5ae401c780*23:53:24* shd = 0x7f5ae401c8e8*23:53:24*
shd_event = 0x0*23:53:24* path = 0x0*23:53:24* subvol
= 0x7f5ae40079e0*23:53:24* this = 0x7f5ae400d540*23:53:24*
crawl_event = 0x7f5ae401d4a0*23:53:24* #11 0x7f5aeaad6de5 in
afr_shd_full_heal (subvol=0x7f5ae40079e0, entry=0x7f5adc00b440,
parent=0x7f5acbffee20, data=0x7f5ae401d490) at
/home/jenkins/root/workspace/centos7-regression/xlators/cluster/afr/src/afr-self-heald.c:541*23:53:24*
healer = 0x7f5ae401d490*23:53:24* this =
0x7f5ae400d540*23:53:24* priv = 0x7f5ae401c780*23:53:24* #12
0x7f5af8737b2f in syncop_ftw (subvol=0x7f5ae40079e0,
loc=0x7f5acbffee20, pid=-6, data=0x7f5ae401d490, fn=0x7f5aeaad6d40
) at
/home/jenkins/root/workspace/centos7-regression/libglusterfs/src/syncop-utils.c:123*23:53:24*
child_loc = {path = 0x0, name = 0x0, inode = 0x0, parent =
0x0, gfid = '\000' , pargfid = '\000' }*23:53:24* fd = 0x7f5ac0001398
Assert for a non-null gfid failed in client_pre_getxattr_v2. From bt, it
looks like a NULL gfid was passed to afr_shd_full.
*23:53:24* __PRETTY_FUNCTION__ =
"client_pre_getxattr_v2"*23:53:24* #5 0x7f5aeada8f2a in
client4_0_getxattr (frame=0x7f5ac0008198, this=0x7f5ae40079e0,
data=0x7f5acbffdcc0) at
/home/jenkins/root/workspace/centos7-regression/xlators/protocol/client/src/client-rpc-fops_v2.c:4287*23:53:24*
conf = 0x7f5ae40293e0*23:53:24* args =
0x7f5acbffdcc0*23:53:24* req = {gfid = '\000' , namelen = 0, name = 0x0, xdata = {xdr_size = 0, count = 0,
pairs = {pairs_len = 0, pairs_val = 0x0}}}*23:53:24* dict =
0x0*23:53:24* ret = 0*23:53:24* op_ret = -1*23:53:24*
op_errno = 116*23:53:24* local =
0x7f5ac00082a8*23:53:24* __FUNCTION__ =
"client4_0_getxattr"*23:53:24* __PRETTY_FUNCTION__ =
"client4_0_getxattr"
regards,
Raghavendra
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Master branch lock down status (Wed, August 08th)
On Fri, Aug 10, 2018 at 1:38 AM, Shyam Ranganathan wrote: > On 08/08/2018 09:04 PM, Shyam Ranganathan wrote: > > Today's patch set 7 [1], included fixes provided till last evening IST, > > and its runs can be seen here [2] (yay! we can link to comments in > > gerrit now). > > > > New failures: (added to the spreadsheet) > > ./tests/bugs/quick-read/bug-846240.t > > The above test fails always if there is a sleep of 10 added at line 36. > > I tried to replicate this in my setup, and was able to do so 3/150 times > and the failures were the same as the ones reported in the build logs > (as below). > > Not finding any clear reason for the failure, I delayed the test (i.e > added a sleep 10) after the open on M0 to see if the race is uncovered, > and it was. > > Du, request you to take a look at the same, as the test is around > quick-read but involves open-behind as well. > Thanks for that information. I'll be working on this today. > Failure snippet: > > 23:41:24 [23:41:28] Running tests in file > ./tests/bugs/quick-read/bug-846240.t > 23:41:28 ./tests/bugs/quick-read/bug-846240.t .. > 23:41:28 1..17 > 23:41:28 ok 1, LINENUM:9 > 23:41:28 ok 2, LINENUM:10 > > 23:41:28 ok 13, LINENUM:40 > 23:41:28 not ok 14 , LINENUM:50 > 23:41:28 FAILED COMMAND: [ 0 -ne 0 ] > > Shyam > ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Master branch lock down status (Thu, August 09th)
Today's test results are updated in the spreadsheet in sheet named "Run patch set 8". I took in patch https://review.gluster.org/c/glusterfs/+/20685 which caused quite a few failures, so not updating new failures as issue yet. Please look at the failures for tests that were retried and passed, as the logs for the initial runs should be preserved from this run onward. Otherwise nothing else to report on the run status, if you are averse to spreadsheets look at this comment in gerrit [1]. Shyam [1] Patch set 8 run status: https://review.gluster.org/c/glusterfs/+/20637/8#message-54de30fa384fd02b0426d9db6d07fad4eeefcf08 On 08/07/2018 07:37 PM, Shyam Ranganathan wrote: > Deserves a new beginning, threads on the other mail have gone deep enough. > > NOTE: (5) below needs your attention, rest is just process and data on > how to find failures. > > 1) We are running the tests using the patch [2]. > > 2) Run details are extracted into a separate sheet in [3] named "Run > Failures" use a search to find a failing test and the corresponding run > that it failed in. > > 3) Patches that are fixing issues can be found here [1], if you think > you have a patch out there, that is not in this list, shout out. > > 4) If you own up a test case failure, update the spreadsheet [3] with > your name against the test, and also update other details as needed (as > comments, as edit rights to the sheet are restricted). > > 5) Current test failures > We still have the following tests failing and some without any RCA or > attention, (If something is incorrect, write back). > > ./tests/bugs/replicate/bug-1290965-detect-bitrotten-objects.t (needs > attention) > ./tests/00-geo-rep/georep-basic-dr-tarssh.t (Kotresh) > ./tests/bugs/glusterd/add-brick-and-validate-replicated-volume-options.t > (Atin) > ./tests/bugs/ec/bug-1236065.t (Ashish) > ./tests/00-geo-rep/georep-basic-dr-rsync.t (Kotresh) > ./tests/basic/ec/ec-1468261.t (needs attention) > ./tests/basic/afr/add-brick-self-heal.t (needs attention) > ./tests/basic/afr/granular-esh/replace-brick.t (needs attention) > ./tests/bugs/core/multiplex-limit-issue-151.t (needs attention) > ./tests/bugs/glusterd/validating-server-quorum.t (Atin) > ./tests/bugs/replicate/bug-1363721.t (Ravi) > > Here are some newer failures, but mostly one-off failures except cores > in ec-5-2.t. All of the following need attention as these are new. > > ./tests/00-geo-rep/00-georep-verify-setup.t > ./tests/basic/afr/gfid-mismatch-resolution-with-fav-child-policy.t > ./tests/basic/stats-dump.t > ./tests/bugs/bug-1110262.t > ./tests/bugs/glusterd/mgmt-handshake-and-volume-sync-post-glusterd-restart.t > ./tests/basic/ec/ec-data-heal.t > ./tests/bugs/replicate/bug-1448804-check-quorum-type-values.t > ./tests/bugs/snapshot/bug-1482023-snpashot-issue-with-other-processes-accessing-mounted-path.t > ./tests/basic/ec/ec-5-2.t > > 6) Tests that are addressed or are not occurring anymore are, > > ./tests/bugs/glusterd/rebalance-operations-in-single-node.t > ./tests/bugs/index/bug-1559004-EMLINK-handling.t > ./tests/bugs/replicate/bug-1386188-sbrain-fav-child.t > ./tests/bugs/replicate/bug-1433571-undo-pending-only-on-up-bricks.t > ./tests/bitrot/bug-1373520.t > ./tests/bugs/distribute/bug-1117851.t > ./tests/bugs/glusterd/quorum-validation.t > ./tests/bugs/distribute/bug-1042725.t > ./tests/bugs/replicate/bug-1586020-mark-dirty-for-entry-txn-on-quorum-failure.t > ./tests/bugs/quota/bug-1293601.t > ./tests/bugs/bug-1368312.t > ./tests/bugs/distribute/bug-1122443.t > ./tests/bugs/core/bug-1432542-mpx-restart-crash.t > > Shyam (and Atin) > > On 08/05/2018 06:24 PM, Shyam Ranganathan wrote: >> Health on master as of the last nightly run [4] is still the same. >> >> Potential patches that rectify the situation (as in [1]) are bunched in >> a patch [2] that Atin and myself have put through several regressions >> (mux, normal and line coverage) and these have also not passed. >> >> Till we rectify the situation we are locking down master branch commit >> rights to the following people, Amar, Atin, Shyam, Vijay. >> >> The intention is to stabilize master and not add more patches that my >> destabilize it. >> >> Test cases that are tracked as failures and need action are present here >> [3]. >> >> @Nigel, request you to apply the commit rights change as you see this >> mail and let the list know regarding the same as well. >> >> Thanks, >> Shyam >> >> [1] Patches that address regression failures: >> https://review.gluster.org/#/q/starredby:srangana%2540redhat.com >> >> [2] Bunched up patch against which regressions were run: >> https://review.gluster.org/#/c/20637 >> >> [3] Failing tests list: >> https://docs.google.com/spreadsheets/d/1IF9GhpKah4bto19RQLr0y_Kkw26E_-crKALHSaSjZMQ/edit?usp=sharing >> >> [4] Nightly run dashboard: https://build.gluster.org/job/nightly-master/ > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > https://lists.gluster.org/mailman/li
Re: [Gluster-devel] Master branch lock down status (Wed, August 08th)
On 08/08/2018 09:04 PM, Shyam Ranganathan wrote: > Today's patch set 7 [1], included fixes provided till last evening IST, > and its runs can be seen here [2] (yay! we can link to comments in > gerrit now). > > New failures: (added to the spreadsheet) > ./tests/bugs/quick-read/bug-846240.t The above test fails always if there is a sleep of 10 added at line 36. I tried to replicate this in my setup, and was able to do so 3/150 times and the failures were the same as the ones reported in the build logs (as below). Not finding any clear reason for the failure, I delayed the test (i.e added a sleep 10) after the open on M0 to see if the race is uncovered, and it was. Du, request you to take a look at the same, as the test is around quick-read but involves open-behind as well. Failure snippet: 23:41:24 [23:41:28] Running tests in file ./tests/bugs/quick-read/bug-846240.t 23:41:28 ./tests/bugs/quick-read/bug-846240.t .. 23:41:28 1..17 23:41:28 ok 1, LINENUM:9 23:41:28 ok 2, LINENUM:10 23:41:28 ok 13, LINENUM:40 23:41:28 not ok 14 , LINENUM:50 23:41:28 FAILED COMMAND: [ 0 -ne 0 ] Shyam ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] afr_set_transaction_flock lead to bad perforance when write with multi-pthread or multi-process
Hi, Gluster expert,
When we setup replicate volume with info like the below:
Volume Name: test
Type: Replicate
Volume ID: 9373eba9-eb84-4618-a54c-f2837345daec
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x (2 + 1) = 3
Transport-type: tcp
Bricks:
Brick1: rcp:/trunk/brick/test1/sn0
Brick2: rcp:/trunk/brick/test1/sn1
Brick3: rcp:/trunk/brick/test1/sn2 (arbiter)
If we run a performance test which could write a same file with multi-pthread
in same time.(write different offset). The write performance drop a lots (about
60%-70% off to the volume which no arbiter)
And when we study the source code, there is a function
“afr_set_transaction_flock” in” afr-transaction.c”,
It will flock the entire file when arbiter_count is not zero, I suppose it is
the root cause lead to performance drop.
Now my question is:
1) Why flock the entire file when arbiter is set on? Could you please share
the detail why it will lead to split brain only to arbiter?
2) If it is the root cause, and it really will lead to split-brain if not
lock entire file, is there any solution to avoid performance drop for this
mulit-write case?
The following is attached source code for this function FYI:
--
int afr_set_transaction_flock (xlator_t *this, afr_local_t *local)
{
afr_internal_lock_t *int_lock = NULL;
afr_private_t *priv = NULL;
int_lock = &local->internal_lock;
priv = this->private;
if ((priv->arbiter_count || local->transaction.eager_lock_on ||
priv->full_lock) &&
local->transaction.type == AFR_DATA_TRANSACTION) {
/*Lock entire file to avoid network split brains.*/
int_lock->flock.l_len = 0;
int_lock->flock.l_start = 0;
} else {
int_lock->flock.l_len = local->transaction.len;
int_lock->flock.l_start = local->transaction.start;
}
int_lock->flock.l_type = F_WRLCK;
return 0;
}
Thanks & Best Regards,
George
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Coverity covscan for 2018-08-09-22d5540f (master branch)
GlusterFS Coverity covscan results for the master branch are available from http://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2018-08-09-22d5540f/ Coverity covscan results for other active branches are also available at http://download.gluster.org/pub/gluster/glusterfs/static-analysis/ ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Spurious smoke failure in build rpms
Infra issue. Please file a bug. On Thu, Aug 9, 2018 at 3:57 PM Pranith Kumar Karampuri wrote: > https://build.gluster.org/job/devrpm-el7/10441/console > > *10:12:42* Wrote: > /home/jenkins/root/workspace/devrpm-el7/extras/LinuxRPM/rpmbuild/SRPMS/glusterfs-4.2dev-0.240.git4657137.el7.src.rpm*10:12:42* > mv rpmbuild/SRPMS/* .*10:12:44* INFO: mock.py version 1.4.11 starting > (python version = 2.7.5)...*10:12:44* Start: init plugins*10:12:44* INFO: > selinux disabled*10:12:44* Finish: init plugins*10:12:44* Start: > run*10:12:44* INFO: Start(glusterfs-4.2dev-0.240.git4657137.el7.src.rpm) > Config(epel-7-x86_64)*10:12:44* Start: clean chroot*10:12:44* ERROR: > Exception(glusterfs-4.2dev-0.240.git4657137.el7.src.rpm) > Config(epel-7-x86_64) 0 minutes 0 seconds > > > I am not sure why it is saying exception for the src.rpm and failing, does > anyone know? > > > -- > Pranith > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-devel -- nigelb ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-Maintainers] Master branch lock down status (Wed, August 08th)
On Thu, Aug 9, 2018 at 6:34 AM Shyam Ranganathan wrote: > Today's patch set 7 [1], included fixes provided till last evening IST, > and its runs can be seen here [2] (yay! we can link to comments in > gerrit now). > > New failures: (added to the spreadsheet) > ./tests/bugs/protocol/bug-808400-repl.t (core dumped) > ./tests/bugs/quick-read/bug-846240.t > > Older tests that had not recurred, but failed today: (moved up in the > spreadsheet) > ./tests/bugs/replicate/bug-1433571-undo-pending-only-on-up-bricks.t > ./tests/bugs/index/bug-1559004-EMLINK-handling.t > The above test is timing out. I had to increase the timeout while adding the .t so that creation of maximum number of links that will max-out in ext4. Will re-check if it is the same issue and get back. > > Other issues; > Test ./tests/basic/ec/ec-5-2.t core dumped again > Few geo-rep failures, Kotresh should have more logs to look at with > these runs > Test ./tests/bugs/glusterd/quorum-validation.t dumped core again > > Atin/Amar, we may need to merge some of the patches that have proven to > be holding up and fixing issues today, so that we do not leave > everything to the last. Check and move them along or lmk. > > Shyam > > [1] Patch set 7: https://review.gluster.org/c/glusterfs/+/20637/7 > [2] Runs against patch set 7 and its status (incomplete as some runs > have not completed): > > https://review.gluster.org/c/glusterfs/+/20637/7#message-37bc68ce6f2157f2947da6fd03b361ab1b0d1a77 > (also updated in the spreadsheet) > > On 08/07/2018 07:37 PM, Shyam Ranganathan wrote: > > Deserves a new beginning, threads on the other mail have gone deep > enough. > > > > NOTE: (5) below needs your attention, rest is just process and data on > > how to find failures. > > > > 1) We are running the tests using the patch [2]. > > > > 2) Run details are extracted into a separate sheet in [3] named "Run > > Failures" use a search to find a failing test and the corresponding run > > that it failed in. > > > > 3) Patches that are fixing issues can be found here [1], if you think > > you have a patch out there, that is not in this list, shout out. > > > > 4) If you own up a test case failure, update the spreadsheet [3] with > > your name against the test, and also update other details as needed (as > > comments, as edit rights to the sheet are restricted). > > > > 5) Current test failures > > We still have the following tests failing and some without any RCA or > > attention, (If something is incorrect, write back). > > > > ./tests/bugs/replicate/bug-1290965-detect-bitrotten-objects.t (needs > > attention) > > ./tests/00-geo-rep/georep-basic-dr-tarssh.t (Kotresh) > > ./tests/bugs/glusterd/add-brick-and-validate-replicated-volume-options.t > > (Atin) > > ./tests/bugs/ec/bug-1236065.t (Ashish) > > ./tests/00-geo-rep/georep-basic-dr-rsync.t (Kotresh) > > ./tests/basic/ec/ec-1468261.t (needs attention) > > ./tests/basic/afr/add-brick-self-heal.t (needs attention) > > ./tests/basic/afr/granular-esh/replace-brick.t (needs attention) > > ./tests/bugs/core/multiplex-limit-issue-151.t (needs attention) > > ./tests/bugs/glusterd/validating-server-quorum.t (Atin) > > ./tests/bugs/replicate/bug-1363721.t (Ravi) > > > > Here are some newer failures, but mostly one-off failures except cores > > in ec-5-2.t. All of the following need attention as these are new. > > > > ./tests/00-geo-rep/00-georep-verify-setup.t > > ./tests/basic/afr/gfid-mismatch-resolution-with-fav-child-policy.t > > ./tests/basic/stats-dump.t > > ./tests/bugs/bug-1110262.t > > > ./tests/bugs/glusterd/mgmt-handshake-and-volume-sync-post-glusterd-restart.t > > ./tests/basic/ec/ec-data-heal.t > > ./tests/bugs/replicate/bug-1448804-check-quorum-type-values.t > > > ./tests/bugs/snapshot/bug-1482023-snpashot-issue-with-other-processes-accessing-mounted-path.t > > ./tests/basic/ec/ec-5-2.t > > > > 6) Tests that are addressed or are not occurring anymore are, > > > > ./tests/bugs/glusterd/rebalance-operations-in-single-node.t > > ./tests/bugs/index/bug-1559004-EMLINK-handling.t > > ./tests/bugs/replicate/bug-1386188-sbrain-fav-child.t > > ./tests/bugs/replicate/bug-1433571-undo-pending-only-on-up-bricks.t > > ./tests/bitrot/bug-1373520.t > > ./tests/bugs/distribute/bug-1117851.t > > ./tests/bugs/glusterd/quorum-validation.t > > ./tests/bugs/distribute/bug-1042725.t > > > ./tests/bugs/replicate/bug-1586020-mark-dirty-for-entry-txn-on-quorum-failure.t > > ./tests/bugs/quota/bug-1293601.t > > ./tests/bugs/bug-1368312.t > > ./tests/bugs/distribute/bug-1122443.t > > ./tests/bugs/core/bug-1432542-mpx-restart-crash.t > > > > Shyam (and Atin) > > > > On 08/05/2018 06:24 PM, Shyam Ranganathan wrote: > >> Health on master as of the last nightly run [4] is still the same. > >> > >> Potential patches that rectify the situation (as in [1]) are bunched in > >> a patch [2] that Atin and myself have put through several regressions > >> (mux, normal and line coverage) and these have also not passed. > >> > >> Till we rectify the situat
[Gluster-devel] Spurious smoke failure in build rpms
https://build.gluster.org/job/devrpm-el7/10441/console *10:12:42* Wrote: /home/jenkins/root/workspace/devrpm-el7/extras/LinuxRPM/rpmbuild/SRPMS/glusterfs-4.2dev-0.240.git4657137.el7.src.rpm*10:12:42* mv rpmbuild/SRPMS/* .*10:12:44* INFO: mock.py version 1.4.11 starting (python version = 2.7.5)...*10:12:44* Start: init plugins*10:12:44* INFO: selinux disabled*10:12:44* Finish: init plugins*10:12:44* Start: run*10:12:44* INFO: Start(glusterfs-4.2dev-0.240.git4657137.el7.src.rpm) Config(epel-7-x86_64)*10:12:44* Start: clean chroot*10:12:44* ERROR: Exception(glusterfs-4.2dev-0.240.git4657137.el7.src.rpm) Config(epel-7-x86_64) 0 minutes 0 seconds I am not sure why it is saying exception for the src.rpm and failing, does anyone know? -- Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-Maintainers] Master branch lock down status
On Wed, Aug 8, 2018 at 5:08 AM Shyam Ranganathan wrote: > Deserves a new beginning, threads on the other mail have gone deep enough. > > NOTE: (5) below needs your attention, rest is just process and data on > how to find failures. > > 1) We are running the tests using the patch [2]. > > 2) Run details are extracted into a separate sheet in [3] named "Run > Failures" use a search to find a failing test and the corresponding run > that it failed in. > > 3) Patches that are fixing issues can be found here [1], if you think > you have a patch out there, that is not in this list, shout out. > > 4) If you own up a test case failure, update the spreadsheet [3] with > your name against the test, and also update other details as needed (as > comments, as edit rights to the sheet are restricted). > > 5) Current test failures > We still have the following tests failing and some without any RCA or > attention, (If something is incorrect, write back). > > ./tests/bugs/replicate/bug-1290965-detect-bitrotten-objects.t (needs > attention) > ./tests/00-geo-rep/georep-basic-dr-tarssh.t (Kotresh) > ./tests/bugs/glusterd/add-brick-and-validate-replicated-volume-options.t > (Atin) > ./tests/bugs/ec/bug-1236065.t (Ashish) > ./tests/00-geo-rep/georep-basic-dr-rsync.t (Kotresh) > ./tests/basic/ec/ec-1468261.t (needs attention) > Sent a fix for above @ https://review.gluster.org/#/c/glusterfs/+/20685 > ./tests/basic/afr/add-brick-self-heal.t (needs attention) > ./tests/basic/afr/granular-esh/replace-brick.t (needs attention) > ./tests/bugs/core/multiplex-limit-issue-151.t (needs attention) > ./tests/bugs/glusterd/validating-server-quorum.t (Atin) > ./tests/bugs/replicate/bug-1363721.t (Ravi) > > Here are some newer failures, but mostly one-off failures except cores > in ec-5-2.t. All of the following need attention as these are new. > > ./tests/00-geo-rep/00-georep-verify-setup.t > ./tests/basic/afr/gfid-mismatch-resolution-with-fav-child-policy.t > ./tests/basic/stats-dump.t > ./tests/bugs/bug-1110262.t > > ./tests/bugs/glusterd/mgmt-handshake-and-volume-sync-post-glusterd-restart.t > ./tests/basic/ec/ec-data-heal.t > ./tests/bugs/replicate/bug-1448804-check-quorum-type-values.t > > ./tests/bugs/snapshot/bug-1482023-snpashot-issue-with-other-processes-accessing-mounted-path.t > ./tests/basic/ec/ec-5-2.t > > 6) Tests that are addressed or are not occurring anymore are, > > ./tests/bugs/glusterd/rebalance-operations-in-single-node.t > ./tests/bugs/index/bug-1559004-EMLINK-handling.t > ./tests/bugs/replicate/bug-1386188-sbrain-fav-child.t > ./tests/bugs/replicate/bug-1433571-undo-pending-only-on-up-bricks.t > ./tests/bitrot/bug-1373520.t > ./tests/bugs/distribute/bug-1117851.t > ./tests/bugs/glusterd/quorum-validation.t > ./tests/bugs/distribute/bug-1042725.t > > ./tests/bugs/replicate/bug-1586020-mark-dirty-for-entry-txn-on-quorum-failure.t > ./tests/bugs/quota/bug-1293601.t > ./tests/bugs/bug-1368312.t > ./tests/bugs/distribute/bug-1122443.t > ./tests/bugs/core/bug-1432542-mpx-restart-crash.t > > Shyam (and Atin) > > On 08/05/2018 06:24 PM, Shyam Ranganathan wrote: > > Health on master as of the last nightly run [4] is still the same. > > > > Potential patches that rectify the situation (as in [1]) are bunched in > > a patch [2] that Atin and myself have put through several regressions > > (mux, normal and line coverage) and these have also not passed. > > > > Till we rectify the situation we are locking down master branch commit > > rights to the following people, Amar, Atin, Shyam, Vijay. > > > > The intention is to stabilize master and not add more patches that my > > destabilize it. > > > > Test cases that are tracked as failures and need action are present here > > [3]. > > > > @Nigel, request you to apply the commit rights change as you see this > > mail and let the list know regarding the same as well. > > > > Thanks, > > Shyam > > > > [1] Patches that address regression failures: > > https://review.gluster.org/#/q/starredby:srangana%2540redhat.com > > > > [2] Bunched up patch against which regressions were run: > > https://review.gluster.org/#/c/20637 > > > > [3] Failing tests list: > > > https://docs.google.com/spreadsheets/d/1IF9GhpKah4bto19RQLr0y_Kkw26E_-crKALHSaSjZMQ/edit?usp=sharing > > > > [4] Nightly run dashboard: https://build.gluster.org/job/nightly-master/ > ___ > maintainers mailing list > maintain...@gluster.org > https://lists.gluster.org/mailman/listinfo/maintainers > -- Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
