Re: [Gluster-devel] This looks like an interesting Gerrit option we could turn on

[Jeff Darcy]

> > label.Label-Name.copyAllScoresOnTrivialRebase
> > 
> > If true, all scores for the label are copied forward when a new patch
> > set is uploaded that is a trivial rebase. A new patch set is considered
> > as trivial rebase if the commit message is the same as in the previous
> > patch set and if it has the same code delta as the previous patch set.
> > This is the case if the change was rebased onto a different parent. This
> > can be used to enable sticky approvals, reducing turn-around for trivial
> > rebases prior to submitting a change. Defaults to false.

"Same code delta" is a bit slippery.  It can't be determined from the
patch itself, because at least line numbers and diff context will have
changed and would need to be ignored to say something's the same.  I
think forwarding scores is valuable enough that I'm in favor of turning
this option on, but we should maintain awareness that scores might get
forwarded in some cases where perhaps they shouldn't.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Rebalance improvement design

[Susant Palai]

Hi Ben,
  Yes we were using pure dist volume. Will check in to your systems for more 
info. 

Can you please update which patch set you used ? In the mean time I will do one 
set of test with the same configuration on a small data set.

Thanks,
Susant


- Original Message -
> From: "Benjamin Turner" 
> To: "Nithya Balachandran" 
> Cc: "Susant Palai" , "Gluster Devel" 
> 
> Sent: Wednesday, April 29, 2015 2:13:05 AM
> Subject: Re: [Gluster-devel] Rebalance improvement design
> 
> I am not seeing the performance you were.  I am running on 500GB of data:
> 
> [root@gqas001 ~]# gluster v rebalance testvol status
>   Node Rebalanced-files
>  size   scanned  failures   skipped   status   run
> time in secs
> -  ---
> ---   ---   ---   --- 
> --
> localhost   129021
> 7.9GB912104 0 0  in progress
> 10100.00
> gqas012.sbu.lab.eng.bos.redhat.com00Bytes
> 1930312 0 0  in progress   10100.00
> gqas003.sbu.lab.eng.bos.redhat.com00Bytes
> 1930312 0 0  in progress   10100.00
> gqas004.sbu.lab.eng.bos.redhat.com   128903 7.9GB
>  946730 0 0  in progress   10100.00
> gqas013.sbu.lab.eng.bos.redhat.com00Bytes
> 1930312 0 0  in progress   10100.00
> gqas014.sbu.lab.eng.bos.redhat.com00Bytes
> 1930312 0 0  in progress   10100.00
> 
> Based on what I am seeing I expect this to take 2 days.  Was you rebal run
> on a pure dist volume?  I am trying on 2x2 + 2 new bricks.  Any idea why
> mine is taking so long?
> 
> -b
> 
> 
> 
> On Wed, Apr 22, 2015 at 1:10 AM, Nithya Balachandran 
> wrote:
> 
> > That sounds great. Thanks.
> >
> > Regards,
> > Nithya
> >
> > - Original Message -
> > From: "Benjamin Turner" 
> > To: "Nithya Balachandran" 
> > Cc: "Susant Palai" , "Gluster Devel" <
> > gluster-devel@gluster.org>
> > Sent: Wednesday, 22 April, 2015 12:14:14 AM
> > Subject: Re: [Gluster-devel] Rebalance improvement design
> >
> > I am setting up a test env now, I'll have some feedback for you this week.
> >
> > -b
> >
> > On Tue, Apr 21, 2015 at 11:36 AM, Nithya Balachandran  > >
> > wrote:
> >
> > > Hi Ben,
> > >
> > > Did you get a chance to try this out?
> > >
> > > Regards,
> > > Nithya
> > >
> > > - Original Message -
> > > From: "Susant Palai" 
> > > To: "Benjamin Turner" 
> > > Cc: "Gluster Devel" 
> > > Sent: Monday, April 13, 2015 9:55:07 AM
> > > Subject: Re: [Gluster-devel] Rebalance improvement design
> > >
> > > Hi Ben,
> > >   Uploaded a new patch here: http://review.gluster.org/#/c/9657/. We can
> > > start perf test on it. :)
> > >
> > > Susant
> > >
> > > - Original Message -
> > > From: "Susant Palai" 
> > > To: "Benjamin Turner" 
> > > Cc: "Gluster Devel" 
> > > Sent: Thursday, 9 April, 2015 3:40:09 PM
> > > Subject: Re: [Gluster-devel] Rebalance improvement design
> > >
> > > Thanks Ben. RPM is not available and I am planning to refresh the patch
> > in
> > > two days with some more regression fixes. I think we can run the tests
> > post
> > > that. Any larger data-set will be good(say 3 to 5 TB).
> > >
> > > Thanks,
> > > Susant
> > >
> > > - Original Message -
> > > From: "Benjamin Turner" 
> > > To: "Vijay Bellur" 
> > > Cc: "Susant Palai" , "Gluster Devel" <
> > > gluster-devel@gluster.org>
> > > Sent: Thursday, 9 April, 2015 2:10:30 AM
> > > Subject: Re: [Gluster-devel] Rebalance improvement design
> > >
> > >
> > > I have some rebalance perf regression stuff I have been working on, is
> > > there an RPM with these patches anywhere so that I can try it on my
> > > systems? If not I'll just build from:
> > >
> > >
> > > git fetch git:// review.gluster.org/glusterfs refs/changes/57/9657/8 &&
> > > git cherry-pick FETCH_HEAD
> > >
> > >
> > >
> > > I will have _at_least_ 10TB of storage, how many TBs of data should I run
> > > with?
> > >
> > >
> > > -b
> > >
> > >
> > > On Tue, Apr 7, 2015 at 9:07 AM, Vijay Bellur < vbel...@redhat.com >
> > wrote:
> > >
> > >
> > >
> > >
> > > On 04/07/2015 03:08 PM, Susant Palai wrote:
> > >
> > >
> > > Here is one test performed on a 300GB data set and around 100%(1/2 the
> > > time) improvement was seen.
> > >
> > > [root@gprfs031 ~]# gluster v i
> > >
> > > Volume Name: rbperf
> > > Type: Distribute
> > > Volume ID: 35562662-337e-4923-b862- d0bbb0748003
> > > Status: Started
> > > Number of Bricks: 4
> > > Transport-type: tcp
> > > Bricks:
> > > Brick1: gprfs029-10ge:/bricks/ gprfs029/brick1
> > > Brick2: gprfs030-10ge:/bricks/ gprfs030/bri

Re: [Gluster-devel] 3.7 bugs need a clone from mainline?

[Ravishankar N]

On 04/29/2015 11:55 AM, Atin Mukherjee wrote:

I've seen few cases where we are using mainline bugs in submitting
patches in 3.7 release. Process wise this looks incorrect to me. IIRC,
earlier the smoke used to complaint about it, but I am not seeing that
either these days. Any recent changes on this?

IMO, we should clone all the mainline bugs which are been fixed for 3.7
and associate 3.7 tracker bugs on them instead of having them in
mainline bugs. Thoughts?
Yes, this is the recommended procedure. Niels had reminded us [1] of 
this some time back..

-Ravi
[1] http://www.gluster.org/pipermail/gluster-devel/2014-June/041232.html

~Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] 3.7 bugs need a clone from mainline?

[Atin Mukherjee]

I've seen few cases where we are using mainline bugs in submitting
patches in 3.7 release. Process wise this looks incorrect to me. IIRC,
earlier the smoke used to complaint about it, but I am not seeing that
either these days. Any recent changes on this?

IMO, we should clone all the mainline bugs which are been fixed for 3.7
and associate 3.7 tracker bugs on them instead of having them in
mainline bugs. Thoughts?

~Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Fwd: FSync tester

[Behrooz Shafiee]

Hello All,

 I was comparing the performance of different GlusterFS clients with each
other and came across an interesting result. I used fsync tester utility (
here  or here
) which basically writes 1MB
to a file (same file, same offset and same size) and calls fsync on that
file and measures the time for fsync( only fsync time, write time is
calculated separately). It repeats the same scenario every 1 seconds. I
tried fsync tester with GlusterFS fuse client, GlusterFS NFS, and my own
filesystem which is also a fuse based file system and uses GlusterFS
libgfapi under the hood to store data. I collected 1000 data points
(latency) for each client and the result is attached to this email. It's
interesting that libgfapi performs almost 3 times better than FUSE and NFS
clients. On the other hand FUSE client of GlusterFS has a very high jitter
compared to the libgfapi and NFS.

Can anyone explain or comment about these results?

Thanks a lot,
-- 
Behrooz
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] This looks like an interesting Gerrit option we could turn on

[Atin Mukherjee]

On 04/28/2015 10:40 PM, Niels de Vos wrote:
> On Tue, Apr 28, 2015 at 05:56:56PM +0100, Justin Clift wrote:
>> This sounds like it might be useful for us:
>>
>>   
>> https://gerrit-documentation.storage.googleapis.com/Documentation/2.9.4/config-labels.html#label_copyAllScoresOnTrivialRebase
> 
> 
> 
> label.Label-Name.copyAllScoresOnTrivialRebase
> 
> If true, all scores for the label are copied forward when a new patch
> set is uploaded that is a trivial rebase. A new patch set is considered
> as trivial rebase if the commit message is the same as in the previous
> patch set and if it has the same code delta as the previous patch set.
> This is the case if the change was rebased onto a different parent. This
> can be used to enable sticky approvals, reducing turn-around for trivial
> rebases prior to submitting a change. Defaults to false.
> 
>> Yes/no/?
> 
> Yes for me.
A big "yes" from me!
> 
> Thanks,
> Niels
> 
> 
> 
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 

-- 
~Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] glusterfs blocked.

[Krishnan Parthasarathi]

> I add some private function in dht_create() as bellow.
> 
> When current pwd is not "/",everything is ok,otherwise,syncop_getxattr will
> be blocked(In target subvol,"server3_3_getxatt" did not run ).
> 
> 
> dict_t *xattr = NULL;
> loc_t loc = {0, };
> memset (loc.gfid, 0, 16);
> loc.gfid[15] = 1;
> ret = syncop_getxattr (subvol, &loc, &xattr,GF_XATTR_PATHINFO_KEY);
Could you post your private patch in this thread? It would be useful to 
discuss the specifics of why glusterfs is blocked.

syncop_XXX functions should be called only from threads other than
threads executing event_dispatch_epoll_handler. You could attach gdb to your 
hung
process and confirm that the syncop_getxattr call is executing on a thread that 
has
event_dispatch_epoll_handler early on its stack.

What is the goal of your private patch? If I may guess, are you trying
to create files on a brick that is on the same machine as your mount point,
when possible? If so, DHT has Non-uniform file allocation policy (NUFA) 
analagous
to NUMA in memory architectures.
For more information, see 
https://github.com/gluster/glusterfs/blob/master/doc/admin-guide/en-US/markdown/admin_managing_volumes.md#non-uniform-file-allocation

HTH,
KP

> 
> Best regards!
> 
> ZTE Information Security Notice: The information contained in this mail (and
> any attachment transmitted herewith) is privileged and confidential and is
> intended for the exclusive use of the addressee(s).  If you are not an
> intended recipient, any disclosure, reproduction, distribution or other
> dissemination or use of the information contained is strictly prohibited.
> If you have received this mail in error, please delete it and notify us
> immediately.
> 
> 
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Rebalance improvement design

[Nithya Balachandran]

Hi Ben,

Is it ok if we take a look at your systems?

Regards,
Nithya

- Original Message -
From: "Benjamin Turner" 
To: "Nithya Balachandran" 
Cc: "Susant Palai" , "Gluster Devel" 

Sent: Wednesday, 29 April, 2015 2:13:05 AM
Subject: Re: [Gluster-devel] Rebalance improvement design

I am not seeing the performance you were.  I am running on 500GB of data:

[root@gqas001 ~]# gluster v rebalance testvol status
  Node Rebalanced-files
 size   scanned  failures   skipped   status   run
time in secs
-  ---
---   ---   ---   --- 
--
localhost   129021
7.9GB912104 0 0  in progress
10100.00
gqas012.sbu.lab.eng.bos.redhat.com00Bytes
1930312 0 0  in progress   10100.00
gqas003.sbu.lab.eng.bos.redhat.com00Bytes
1930312 0 0  in progress   10100.00
gqas004.sbu.lab.eng.bos.redhat.com   128903 7.9GB
 946730 0 0  in progress   10100.00
gqas013.sbu.lab.eng.bos.redhat.com00Bytes
1930312 0 0  in progress   10100.00
gqas014.sbu.lab.eng.bos.redhat.com00Bytes
1930312 0 0  in progress   10100.00

Based on what I am seeing I expect this to take 2 days.  Was you rebal run
on a pure dist volume?  I am trying on 2x2 + 2 new bricks.  Any idea why
mine is taking so long?

-b



On Wed, Apr 22, 2015 at 1:10 AM, Nithya Balachandran 
wrote:

> That sounds great. Thanks.
>
> Regards,
> Nithya
>
> - Original Message -
> From: "Benjamin Turner" 
> To: "Nithya Balachandran" 
> Cc: "Susant Palai" , "Gluster Devel" <
> gluster-devel@gluster.org>
> Sent: Wednesday, 22 April, 2015 12:14:14 AM
> Subject: Re: [Gluster-devel] Rebalance improvement design
>
> I am setting up a test env now, I'll have some feedback for you this week.
>
> -b
>
> On Tue, Apr 21, 2015 at 11:36 AM, Nithya Balachandran  >
> wrote:
>
> > Hi Ben,
> >
> > Did you get a chance to try this out?
> >
> > Regards,
> > Nithya
> >
> > - Original Message -
> > From: "Susant Palai" 
> > To: "Benjamin Turner" 
> > Cc: "Gluster Devel" 
> > Sent: Monday, April 13, 2015 9:55:07 AM
> > Subject: Re: [Gluster-devel] Rebalance improvement design
> >
> > Hi Ben,
> >   Uploaded a new patch here: http://review.gluster.org/#/c/9657/. We can
> > start perf test on it. :)
> >
> > Susant
> >
> > - Original Message -
> > From: "Susant Palai" 
> > To: "Benjamin Turner" 
> > Cc: "Gluster Devel" 
> > Sent: Thursday, 9 April, 2015 3:40:09 PM
> > Subject: Re: [Gluster-devel] Rebalance improvement design
> >
> > Thanks Ben. RPM is not available and I am planning to refresh the patch
> in
> > two days with some more regression fixes. I think we can run the tests
> post
> > that. Any larger data-set will be good(say 3 to 5 TB).
> >
> > Thanks,
> > Susant
> >
> > - Original Message -
> > From: "Benjamin Turner" 
> > To: "Vijay Bellur" 
> > Cc: "Susant Palai" , "Gluster Devel" <
> > gluster-devel@gluster.org>
> > Sent: Thursday, 9 April, 2015 2:10:30 AM
> > Subject: Re: [Gluster-devel] Rebalance improvement design
> >
> >
> > I have some rebalance perf regression stuff I have been working on, is
> > there an RPM with these patches anywhere so that I can try it on my
> > systems? If not I'll just build from:
> >
> >
> > git fetch git:// review.gluster.org/glusterfs refs/changes/57/9657/8 &&
> > git cherry-pick FETCH_HEAD
> >
> >
> >
> > I will have _at_least_ 10TB of storage, how many TBs of data should I run
> > with?
> >
> >
> > -b
> >
> >
> > On Tue, Apr 7, 2015 at 9:07 AM, Vijay Bellur < vbel...@redhat.com >
> wrote:
> >
> >
> >
> >
> > On 04/07/2015 03:08 PM, Susant Palai wrote:
> >
> >
> > Here is one test performed on a 300GB data set and around 100%(1/2 the
> > time) improvement was seen.
> >
> > [root@gprfs031 ~]# gluster v i
> >
> > Volume Name: rbperf
> > Type: Distribute
> > Volume ID: 35562662-337e-4923-b862- d0bbb0748003
> > Status: Started
> > Number of Bricks: 4
> > Transport-type: tcp
> > Bricks:
> > Brick1: gprfs029-10ge:/bricks/ gprfs029/brick1
> > Brick2: gprfs030-10ge:/bricks/ gprfs030/brick1
> > Brick3: gprfs031-10ge:/bricks/ gprfs031/brick1
> > Brick4: gprfs032-10ge:/bricks/ gprfs032/brick1
> >
> >
> > Added server 32 and started rebalance force.
> >
> > Rebalance stat for new changes:
> > [root@gprfs031 ~]# gluster v rebalance rbperf status
> > Node Rebalanced-files size scanned failures skipped status run time in
> secs
> > - --- --- --- --- ---
> >  --
> > localhost 74639 36.1GB 29

Re: [Gluster-devel] Rebalance improvement design

[Benjamin Turner]

I am not seeing the performance you were.  I am running on 500GB of data:

[root@gqas001 ~]# gluster v rebalance testvol status
  Node Rebalanced-files
 size   scanned  failures   skipped   status   run
time in secs
-  ---
---   ---   ---   --- 
--
localhost   129021
7.9GB912104 0 0  in progress
10100.00
gqas012.sbu.lab.eng.bos.redhat.com00Bytes
1930312 0 0  in progress   10100.00
gqas003.sbu.lab.eng.bos.redhat.com00Bytes
1930312 0 0  in progress   10100.00
gqas004.sbu.lab.eng.bos.redhat.com   128903 7.9GB
 946730 0 0  in progress   10100.00
gqas013.sbu.lab.eng.bos.redhat.com00Bytes
1930312 0 0  in progress   10100.00
gqas014.sbu.lab.eng.bos.redhat.com00Bytes
1930312 0 0  in progress   10100.00

Based on what I am seeing I expect this to take 2 days.  Was you rebal run
on a pure dist volume?  I am trying on 2x2 + 2 new bricks.  Any idea why
mine is taking so long?

-b



On Wed, Apr 22, 2015 at 1:10 AM, Nithya Balachandran 
wrote:

> That sounds great. Thanks.
>
> Regards,
> Nithya
>
> - Original Message -
> From: "Benjamin Turner" 
> To: "Nithya Balachandran" 
> Cc: "Susant Palai" , "Gluster Devel" <
> gluster-devel@gluster.org>
> Sent: Wednesday, 22 April, 2015 12:14:14 AM
> Subject: Re: [Gluster-devel] Rebalance improvement design
>
> I am setting up a test env now, I'll have some feedback for you this week.
>
> -b
>
> On Tue, Apr 21, 2015 at 11:36 AM, Nithya Balachandran  >
> wrote:
>
> > Hi Ben,
> >
> > Did you get a chance to try this out?
> >
> > Regards,
> > Nithya
> >
> > - Original Message -
> > From: "Susant Palai" 
> > To: "Benjamin Turner" 
> > Cc: "Gluster Devel" 
> > Sent: Monday, April 13, 2015 9:55:07 AM
> > Subject: Re: [Gluster-devel] Rebalance improvement design
> >
> > Hi Ben,
> >   Uploaded a new patch here: http://review.gluster.org/#/c/9657/. We can
> > start perf test on it. :)
> >
> > Susant
> >
> > - Original Message -
> > From: "Susant Palai" 
> > To: "Benjamin Turner" 
> > Cc: "Gluster Devel" 
> > Sent: Thursday, 9 April, 2015 3:40:09 PM
> > Subject: Re: [Gluster-devel] Rebalance improvement design
> >
> > Thanks Ben. RPM is not available and I am planning to refresh the patch
> in
> > two days with some more regression fixes. I think we can run the tests
> post
> > that. Any larger data-set will be good(say 3 to 5 TB).
> >
> > Thanks,
> > Susant
> >
> > - Original Message -
> > From: "Benjamin Turner" 
> > To: "Vijay Bellur" 
> > Cc: "Susant Palai" , "Gluster Devel" <
> > gluster-devel@gluster.org>
> > Sent: Thursday, 9 April, 2015 2:10:30 AM
> > Subject: Re: [Gluster-devel] Rebalance improvement design
> >
> >
> > I have some rebalance perf regression stuff I have been working on, is
> > there an RPM with these patches anywhere so that I can try it on my
> > systems? If not I'll just build from:
> >
> >
> > git fetch git:// review.gluster.org/glusterfs refs/changes/57/9657/8 &&
> > git cherry-pick FETCH_HEAD
> >
> >
> >
> > I will have _at_least_ 10TB of storage, how many TBs of data should I run
> > with?
> >
> >
> > -b
> >
> >
> > On Tue, Apr 7, 2015 at 9:07 AM, Vijay Bellur < vbel...@redhat.com >
> wrote:
> >
> >
> >
> >
> > On 04/07/2015 03:08 PM, Susant Palai wrote:
> >
> >
> > Here is one test performed on a 300GB data set and around 100%(1/2 the
> > time) improvement was seen.
> >
> > [root@gprfs031 ~]# gluster v i
> >
> > Volume Name: rbperf
> > Type: Distribute
> > Volume ID: 35562662-337e-4923-b862- d0bbb0748003
> > Status: Started
> > Number of Bricks: 4
> > Transport-type: tcp
> > Bricks:
> > Brick1: gprfs029-10ge:/bricks/ gprfs029/brick1
> > Brick2: gprfs030-10ge:/bricks/ gprfs030/brick1
> > Brick3: gprfs031-10ge:/bricks/ gprfs031/brick1
> > Brick4: gprfs032-10ge:/bricks/ gprfs032/brick1
> >
> >
> > Added server 32 and started rebalance force.
> >
> > Rebalance stat for new changes:
> > [root@gprfs031 ~]# gluster v rebalance rbperf status
> > Node Rebalanced-files size scanned failures skipped status run time in
> secs
> > - --- --- --- --- ---
> >  --
> > localhost 74639 36.1GB 297319 0 0 completed 1743.00
> > 172.17.40.30 67512 33.5GB 269187 0 0 completed 1395.00
> > gprfs029-10ge 79095 38.8GB 284105 0 0 completed 1559.00
> > gprfs032-10ge 0 0Bytes 0 0 0 completed 402.00
> > volume rebalance: rbperf: success:
> >
> > Rebalance stat for old model:
> > [root@gprfs031 ~

Re: [Gluster-devel] This looks like an interesting Gerrit option we could turn on

[Vijay Bellur]

On 04/28/2015 10:55 PM, Shyam wrote:

On 04/28/2015 01:10 PM, Niels de Vos wrote:

On Tue, Apr 28, 2015 at 05:56:56PM +0100, Justin Clift wrote:

This sounds like it might be useful for us:


https://gerrit-documentation.storage.googleapis.com/Documentation/2.9.4/config-labels.html#label_copyAllScoresOnTrivialRebase





label.Label-Name.copyAllScoresOnTrivialRebase

If true, all scores for the label are copied forward when a new patch
set is uploaded that is a trivial rebase. A new patch set is considered
as trivial rebase if the commit message is the same as in the previous
patch set and if it has the same code delta as the previous patch set.
This is the case if the change was rebased onto a different parent. This
can be used to enable sticky approvals, reducing turn-around for trivial
rebases prior to submitting a change. Defaults to false.


Yes/no/?


Yes for me.

Yes ++ (if above is true ;) )




Recollect seeing similar behavior in openstack CI infrastructure. Should 
be good to flip it on.


-Vijay

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] This looks like an interesting Gerrit option we could turn on

[Shyam]

On 04/28/2015 01:10 PM, Niels de Vos wrote:

On Tue, Apr 28, 2015 at 05:56:56PM +0100, Justin Clift wrote:

This sounds like it might be useful for us:

   
https://gerrit-documentation.storage.googleapis.com/Documentation/2.9.4/config-labels.html#label_copyAllScoresOnTrivialRebase




label.Label-Name.copyAllScoresOnTrivialRebase

If true, all scores for the label are copied forward when a new patch
set is uploaded that is a trivial rebase. A new patch set is considered
as trivial rebase if the commit message is the same as in the previous
patch set and if it has the same code delta as the previous patch set.
This is the case if the change was rebased onto a different parent. This
can be used to enable sticky approvals, reducing turn-around for trivial
rebases prior to submitting a change. Defaults to false.


Yes/no/?


Yes for me.

Yes ++ (if above is true ;) )


Thanks,
Niels



___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] This looks like an interesting Gerrit option we could turn on

[Niels de Vos]

On Tue, Apr 28, 2015 at 05:56:56PM +0100, Justin Clift wrote:
> This sounds like it might be useful for us:
> 
>   
> https://gerrit-documentation.storage.googleapis.com/Documentation/2.9.4/config-labels.html#label_copyAllScoresOnTrivialRebase



label.Label-Name.copyAllScoresOnTrivialRebase

If true, all scores for the label are copied forward when a new patch
set is uploaded that is a trivial rebase. A new patch set is considered
as trivial rebase if the commit message is the same as in the previous
patch set and if it has the same code delta as the previous patch set.
This is the case if the change was rebased onto a different parent. This
can be used to enable sticky approvals, reducing turn-around for trivial
rebases prior to submitting a change. Defaults to false.

> Yes/no/?

Yes for me.

Thanks,
Niels


pgpyQKuzx5uGE.pgp
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] This looks like an interesting Gerrit option we could turn on

[Justin Clift]

This sounds like it might be useful for us:

  
https://gerrit-documentation.storage.googleapis.com/Documentation/2.9.4/config-labels.html#label_copyAllScoresOnTrivialRebase

Yes/no/?

+ 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://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Update on mgmt_v3-locks.t failure in netbsd

[Kaushal M]

Posted changes for review,
https://review.gluster.org/10425
https://review.gluster.org/10426

~kaushal

On Tue, Apr 28, 2015 at 6:34 PM, Kaushal M  wrote:
> After a long discussion (not really), we've concluded that a 64-bit
> uint is really overkill for how we are using the generation number,
> and I'll change it to a 32-bit uint. I'll send a change to do this
> right away.
>
> The generation number we use is not permanent, it is valid only within
> a GlusterD processe's lifetime. It starts fresh on every GlusterD
> start. We don't save it or restore it. The generation number is bumped
> for each peerinfo object allocated. Considering this, even if were to
> do peer probes every second it'd be ages before we overflow with a
> 32-bit generation number. If someone is somehow able to bombard us
> with 4 billion requests, I expect GlusterD to bork before the
> generation number ever reaches the overflow point.
>
> ~kaushal
>
> On Tue, Apr 28, 2015 at 6:13 PM, Emmanuel Dreyfus  wrote:
>> On Tue, Apr 28, 2015 at 06:08:45PM +0530, Vijay Bellur wrote:
>>> Let us retain support for 32-bit platforms. Though as developers we do not
>>> run many tests on non 64-bit platforms, it would be not be good to break
>>> compatibility for 32-bit platforms as we have many community users running
>>> this
>>
>> That is a point in favor of not migrating NetBSD slave VM running
>> regression to 64 bit systems. Keeping them as is will catch any
>> 32 bit regressuin.
>>
>> --
>> Emmanuel Dreyfus
>> m...@netbsd.org
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Update on mgmt_v3-locks.t failure in netbsd

[Kaushal M]

After a long discussion (not really), we've concluded that a 64-bit
uint is really overkill for how we are using the generation number,
and I'll change it to a 32-bit uint. I'll send a change to do this
right away.

The generation number we use is not permanent, it is valid only within
a GlusterD processe's lifetime. It starts fresh on every GlusterD
start. We don't save it or restore it. The generation number is bumped
for each peerinfo object allocated. Considering this, even if were to
do peer probes every second it'd be ages before we overflow with a
32-bit generation number. If someone is somehow able to bombard us
with 4 billion requests, I expect GlusterD to bork before the
generation number ever reaches the overflow point.

~kaushal

On Tue, Apr 28, 2015 at 6:13 PM, Emmanuel Dreyfus  wrote:
> On Tue, Apr 28, 2015 at 06:08:45PM +0530, Vijay Bellur wrote:
>> Let us retain support for 32-bit platforms. Though as developers we do not
>> run many tests on non 64-bit platforms, it would be not be good to break
>> compatibility for 32-bit platforms as we have many community users running
>> this
>
> That is a point in favor of not migrating NetBSD slave VM running
> regression to 64 bit systems. Keeping them as is will catch any
> 32 bit regressuin.
>
> --
> Emmanuel Dreyfus
> m...@netbsd.org
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Update on mgmt_v3-locks.t failure in netbsd

[Atin Mukherjee]

On 04/28/2015 06:08 PM, Vijay Bellur wrote:
> On 04/28/2015 05:48 PM, Kaushal M wrote:
>> AFAIU we've not officially supported 32-bit architectures for sometime
>> (possibly for ever) as a community. But we had users running it
>> anyway.
>>
>> 3.7 as it is currently, cannot run on 32-bit platforms. I've used
>> atomic operations which depend on specific processor instructions, to
>> increment a 64-bit (uint64_t) generation number. This is not possible
>> on 32-bit platforms.
>>
>> I'm currently debating with myself and others around me, if we can be
>> satisfied with using a 32-bit generation number. I used a 64-bit
>> generation number, just to give us the widest possible range before
>> running out. But a 32-bit generation number should be more than enough
>> for normal usage.
>>
>> I'll update the list once we come to a decision.
>>
> 
> Let us retain support for 32-bit platforms. Though as developers we do
> not run many tests on non 64-bit platforms, it would be not be good to
> break compatibility for 32-bit platforms as we have many community users
> running this
To get rid of all this fuss, I think its better to use uint32_t instead
of unint64_t.
> 
> -Vijay
> 
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel

-- 
~Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Update on mgmt_v3-locks.t failure in netbsd

[Emmanuel Dreyfus]

On Tue, Apr 28, 2015 at 06:08:45PM +0530, Vijay Bellur wrote:
> Let us retain support for 32-bit platforms. Though as developers we do not
> run many tests on non 64-bit platforms, it would be not be good to break
> compatibility for 32-bit platforms as we have many community users running
> this

That is a point in favor of not migrating NetBSD slave VM running 
regression to 64 bit systems. Keeping them as is will catch any 
32 bit regressuin.

-- 
Emmanuel Dreyfus
m...@netbsd.org
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Meeting minutes of todays Gluster Community Bug Triage meeting

[Niels de Vos]

On Tue, Apr 28, 2015 at 12:58:24PM +0200, Niels de Vos wrote:
> 
> Hi all,
> 
> This meeting is scheduled for anyone that is interested in lssisting
> with, or learning more about Bug Triage.
> 
> Meeting details:
> - location: #gluster-meeting on Freenode IRC
> ( https://webchat.freenode.net/?channels=gluster-meeting )
> - date: every Tuesday
> - time: 12:00 UTC
> (in your terminal, run: date -d "12:00 UTC")
> - agenda: https://public.pad.fsfe.org/p/gluster-bug-triage
> 
> Currently the following items are listed:
> * Roll Call
> * Status of last weeks action items
> * Group Triage
> * Open Floor
> 
> The last two topics have space for additions. If you have a suitable bug
> or topic to discuss, please add it to the agenda.


Minutes: 
http://meetbot.fedoraproject.org/gluster-meeting/2015-04-28/gluster-meeting.2015-04-28-12.01.html
Minutes (text): 
http://meetbot.fedoraproject.org/gluster-meeting/2015-04-28/gluster-meeting.2015-04-28-12.01.txt
Log: 
http://meetbot.fedoraproject.org/gluster-meeting/2015-04-28/gluster-meeting.2015-04-28-12.01.log.html


Meeting summary
---
* Agenda: https://public.pad.fsfe.org/p/gluster-bug-triage  (ndevos,
  12:01:28)
* Roll Call  (ndevos, 12:01:33)

* Status of last weeks action items  (ndevos, 12:03:28)

* Group Triage  (ndevos, 12:07:22)
  * 27 bugs to triage  (ndevos, 12:08:20)
  * LINK: http://goo.gl/WuDQun is the url for today  (ndevos, 12:08:30)
  * If you like to triage more bugs, please check
https://public.pad.fsfe.org/p/gluster-bug-triage for links to older
bugs and other components  (ndevos, 12:27:45)

* Open Floor  (ndevos, 12:28:01)
  * LINK: https://github.com/gluster/gluster-bugs-webui/issues contains
some more ideas on what to add, please add your RFE's there too
(ndevos, 12:29:25)
  * LINK:
http://download.gluster.org/pub/gluster/glusterfs/static-analysis/
(hchiramm, 12:30:05)
  * LINK:

http://download.gluster.org/pub/gluster/glusterfs/static-analysis/release-3.7/glusterfs-coverity/
(hchiramm, 12:35:59)

Meeting ended at 12:41:27 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* ndevos (51)
* hchiramm (42)
* kkeithley_ (29)
* soumya (6)
* jiffin (5)
* hagarth (4)
* zodbot (3)
* atinmu (2)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot


pgpoGrC2PDNrX.pgp
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Update on mgmt_v3-locks.t failure in netbsd

[Emmanuel Dreyfus]

On Tue, Apr 28, 2015 at 05:15:30PM +0530, Kaushal M wrote:
> Because of this CAA_BITS_PER_LONG is set to 32 and the case for size 8
> isn't compiled in uatomic_add_return. Even though the underlying
> (virtual) hardware has 64-bit support, and supports the required
> 8-byte wide instrcution, it cannot be used because we are running on a
> 32-bit kernel with a 32-bit userspace.

NetBSD has a non-standard atomic_add_64() available on alpha, amd64, 
ia64 and suprisingly i386. It is also availaible for some sparc, mips
and powerpc CPU.

> Manu, was there any particular reason why you 32-bit NetBSD? If there
> are none, can you please replace the VMs with 64-bit NetBSD. Until
> then you can keep mgmt_v3-locks.t disabled.

Well, I was not even aware 32 bits machine were not supported. That is
a huge blow to portability, especialy considering that i386 seems capable
of handling 64 bit atomic operations.

At a minimum we should introduce a gf_atomic_add() macro that exapnds
to approproiate non standard stuff. But why so we need 64 bits here? What
is the requirement?


-- 
Emmanuel Dreyfus
m...@netbsd.org
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Update on mgmt_v3-locks.t failure in netbsd

[Vijay Bellur]

On 04/28/2015 05:48 PM, Kaushal M wrote:

AFAIU we've not officially supported 32-bit architectures for sometime
(possibly for ever) as a community. But we had users running it
anyway.

3.7 as it is currently, cannot run on 32-bit platforms. I've used
atomic operations which depend on specific processor instructions, to
increment a 64-bit (uint64_t) generation number. This is not possible
on 32-bit platforms.

I'm currently debating with myself and others around me, if we can be
satisfied with using a 32-bit generation number. I used a 64-bit
generation number, just to give us the widest possible range before
running out. But a 32-bit generation number should be more than enough
for normal usage.

I'll update the list once we come to a decision.



Let us retain support for 32-bit platforms. Though as developers we do 
not run many tests on non 64-bit platforms, it would be not be good to 
break compatibility for 32-bit platforms as we have many community users 
running this


-Vijay

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Update on mgmt_v3-locks.t failure in netbsd

[Joe Julian]

No Raspberry Pi servers any more? 

On April 28, 2015 5:07:06 AM PDT, Justin Clift  wrote:
>Does this mean we're officially no longer supporting 32 bit
>architectures?
>
>(or is that just on x86?)
>
>+ Justin
>
>
>On 28 Apr 2015, at 12:45, Kaushal M  wrote:
>> Found the problem. The NetBSD slaves are running a 32-bit kernel and
>userspace.
>> ```
>> nbslave7a# uname -p
>> i386
>> ```
>> 
>> Because of this CAA_BITS_PER_LONG is set to 32 and the case for size
>8
>> isn't compiled in uatomic_add_return. Even though the underlying
>> (virtual) hardware has 64-bit support, and supports the required
>> 8-byte wide instrcution, it cannot be used because we are running on
>a
>> 32-bit kernel with a 32-bit userspace.
>> 
>> Manu, was there any particular reason why you 32-bit NetBSD? If there
>> are none, can you please replace the VMs with 64-bit NetBSD. Until
>> then you can keep mgmt_v3-locks.t disabled.
>> 
>> ~kaushal
>> 
>> On Tue, Apr 28, 2015 at 4:56 PM, Kaushal M 
>wrote:
>>> I seem to have found the issue.
>>> 
>>> The uatomic_add_return function is defined in urcu/uatomic.h as
>>> ```
>>> /* uatomic_add_return */
>>> 
>>> static inline __attribute__((always_inline))
>>> unsigned long __uatomic_add_return(void *addr, unsigned long val,
>>>int len)
>>> {
>>>   switch (len) {
>>>   case 1:
>>>   {
>>>   unsigned char result = val;
>>> 
>>>   __asm__ __volatile__(
>>>   "lock; xaddb %1, %0"
>>>   : "+m"(*__hp(addr)), "+q" (result)
>>>   :
>>>   : "memory");
>>>   return result + (unsigned char)val;
>>>   }
>>>   case 2:
>>>   {
>>>   unsigned short result = val;
>>> 
>>>   __asm__ __volatile__(
>>>   "lock; xaddw %1, %0"
>>>   : "+m"(*__hp(addr)), "+r" (result)
>>>   :
>>>   : "memory");
>>>   return result + (unsigned short)val;
>>>   }
>>>   case 4:
>>>   {
>>>   unsigned int result = val;
>>> 
>>>   __asm__ __volatile__(
>>>   "lock; xaddl %1, %0"
>>>   : "+m"(*__hp(addr)), "+r" (result)
>>>   :
>>>   : "memory");
>>>   return result + (unsigned int)val;
>>>   }
>>> #if (CAA_BITS_PER_LONG == 64)
>>>   case 8:
>>>   {
>>>   unsigned long result = val;
>>> 
>>>   __asm__ __volatile__(
>>>   "lock; xaddq %1, %0"
>>>   : "+m"(*__hp(addr)), "+r" (result)
>>>   :
>>>   : "memory");
>>>   return result + (unsigned long)val;
>>>   }
>>> #endif
>>>   }
>>>   /*
>>>* generate an illegal instruction. Cannot catch this with
>>>* linker tricks when optimizations are disabled.
>>>*/
>>>   __asm__ __volatile__("ud2");
>>>   return 0;
>>> }
>>> ```
>>> 
>>> As we can see, uatomic_add_return uses different assembly
>instructions
>>> to perform the add based on the size of the datatype of the value.
>If
>>> the size of the value doesn't exactly match one of the sizes in the
>>> switch case, it deliberately generates a SIGILL.
>>> 
>>> The case for size 8, is conditionally compiled as we can see above.
>>> From the backtrace Atin provided earlier, we see that the size of
>the
>>> value is indeed 8 (we use uint64_t). Because we had a SIGILL, we can
>>> conclude that the case for size 8 wasn't compiled.
>>> 
>>> I don't know why this compilation didn't (or as this is in a header
>>> file, doesn't) happen on the NetBSD slaves and this is something I'd
>>> like to find out.
>>> 
>>> ~kaushal
>>> 
>>> On Tue, Apr 28, 2015 at 1:50 PM, Anand Nekkunti
> wrote:
 
 On 04/28/2015 01:40 PM, Emmanuel Dreyfus wrote:
> 
> On Tue, Apr 28, 2015 at 01:37:42PM +0530, Anand Nekkunti wrote:
>> 
>>__asm__ is for to write assembly code in c (gcc),
>> __volatile__(:::)
>> compiler level  barrier to force the compiler not to do reorder
>the
>> instructions(to avoid optimization ) .
> 
> Sure, but the gory details should be of no interest to the
>developer
> engaged in debug: if it crashes this is probably because it is
>called
> with wrong arguments, hence the question:
>  ccing gluster-devel
>>> 
>>> new_peer->generation = uatomic_add_return
>(&conf->generation,
>>> 1);
>>> Are new_peer->generation and conf->generation sane?
 
 
 ___
 Gluster-devel mailing list
 Gluster-devel@gluster.org
 http://www.gluster.org/mailman/listinfo/gluster-devel
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>
>--
>GlusterFS - http://www.gluster.org
>

Re: [Gluster-devel] Update on mgmt_v3-locks.t failure in netbsd

[Kaushal M]

AFAIU we've not officially supported 32-bit architectures for sometime
(possibly for ever) as a community. But we had users running it
anyway.

3.7 as it is currently, cannot run on 32-bit platforms. I've used
atomic operations which depend on specific processor instructions, to
increment a 64-bit (uint64_t) generation number. This is not possible
on 32-bit platforms.

I'm currently debating with myself and others around me, if we can be
satisfied with using a 32-bit generation number. I used a 64-bit
generation number, just to give us the widest possible range before
running out. But a 32-bit generation number should be more than enough
for normal usage.

I'll update the list once we come to a decision.

~kaushal

On Tue, Apr 28, 2015 at 5:37 PM, Justin Clift  wrote:
> Does this mean we're officially no longer supporting 32 bit architectures?
>
> (or is that just on x86?)
>
> + Justin
>
>
> On 28 Apr 2015, at 12:45, Kaushal M  wrote:
>> Found the problem. The NetBSD slaves are running a 32-bit kernel and 
>> userspace.
>> ```
>> nbslave7a# uname -p
>> i386
>> ```
>>
>> Because of this CAA_BITS_PER_LONG is set to 32 and the case for size 8
>> isn't compiled in uatomic_add_return. Even though the underlying
>> (virtual) hardware has 64-bit support, and supports the required
>> 8-byte wide instrcution, it cannot be used because we are running on a
>> 32-bit kernel with a 32-bit userspace.
>>
>> Manu, was there any particular reason why you 32-bit NetBSD? If there
>> are none, can you please replace the VMs with 64-bit NetBSD. Until
>> then you can keep mgmt_v3-locks.t disabled.
>>
>> ~kaushal
>>
>> On Tue, Apr 28, 2015 at 4:56 PM, Kaushal M  wrote:
>>> I seem to have found the issue.
>>>
>>> The uatomic_add_return function is defined in urcu/uatomic.h as
>>> ```
>>> /* uatomic_add_return */
>>>
>>> static inline __attribute__((always_inline))
>>> unsigned long __uatomic_add_return(void *addr, unsigned long val,
>>>int len)
>>> {
>>>   switch (len) {
>>>   case 1:
>>>   {
>>>   unsigned char result = val;
>>>
>>>   __asm__ __volatile__(
>>>   "lock; xaddb %1, %0"
>>>   : "+m"(*__hp(addr)), "+q" (result)
>>>   :
>>>   : "memory");
>>>   return result + (unsigned char)val;
>>>   }
>>>   case 2:
>>>   {
>>>   unsigned short result = val;
>>>
>>>   __asm__ __volatile__(
>>>   "lock; xaddw %1, %0"
>>>   : "+m"(*__hp(addr)), "+r" (result)
>>>   :
>>>   : "memory");
>>>   return result + (unsigned short)val;
>>>   }
>>>   case 4:
>>>   {
>>>   unsigned int result = val;
>>>
>>>   __asm__ __volatile__(
>>>   "lock; xaddl %1, %0"
>>>   : "+m"(*__hp(addr)), "+r" (result)
>>>   :
>>>   : "memory");
>>>   return result + (unsigned int)val;
>>>   }
>>> #if (CAA_BITS_PER_LONG == 64)
>>>   case 8:
>>>   {
>>>   unsigned long result = val;
>>>
>>>   __asm__ __volatile__(
>>>   "lock; xaddq %1, %0"
>>>   : "+m"(*__hp(addr)), "+r" (result)
>>>   :
>>>   : "memory");
>>>   return result + (unsigned long)val;
>>>   }
>>> #endif
>>>   }
>>>   /*
>>>* generate an illegal instruction. Cannot catch this with
>>>* linker tricks when optimizations are disabled.
>>>*/
>>>   __asm__ __volatile__("ud2");
>>>   return 0;
>>> }
>>> ```
>>>
>>> As we can see, uatomic_add_return uses different assembly instructions
>>> to perform the add based on the size of the datatype of the value. If
>>> the size of the value doesn't exactly match one of the sizes in the
>>> switch case, it deliberately generates a SIGILL.
>>>
>>> The case for size 8, is conditionally compiled as we can see above.
>>> From the backtrace Atin provided earlier, we see that the size of the
>>> value is indeed 8 (we use uint64_t). Because we had a SIGILL, we can
>>> conclude that the case for size 8 wasn't compiled.
>>>
>>> I don't know why this compilation didn't (or as this is in a header
>>> file, doesn't) happen on the NetBSD slaves and this is something I'd
>>> like to find out.
>>>
>>> ~kaushal
>>>
>>> On Tue, Apr 28, 2015 at 1:50 PM, Anand Nekkunti  wrote:

 On 04/28/2015 01:40 PM, Emmanuel Dreyfus wrote:
>
> On Tue, Apr 28, 2015 at 01:37:42PM +0530, Anand Nekkunti wrote:
>>
>>__asm__ is for to write assembly code in c (gcc),
>> __volatile__(:::)
>> compiler level  barrier to force the compiler not to do reorder the
>> instructions(to avoid optimization ) .
>
> Sure, but the gory details should be of no interest to the developer
> engaged in debug: if it crashes this 

Re: [Gluster-devel] Update on mgmt_v3-locks.t failure in netbsd

[Justin Clift]

Does this mean we're officially no longer supporting 32 bit architectures?

(or is that just on x86?)

+ Justin


On 28 Apr 2015, at 12:45, Kaushal M  wrote:
> Found the problem. The NetBSD slaves are running a 32-bit kernel and 
> userspace.
> ```
> nbslave7a# uname -p
> i386
> ```
> 
> Because of this CAA_BITS_PER_LONG is set to 32 and the case for size 8
> isn't compiled in uatomic_add_return. Even though the underlying
> (virtual) hardware has 64-bit support, and supports the required
> 8-byte wide instrcution, it cannot be used because we are running on a
> 32-bit kernel with a 32-bit userspace.
> 
> Manu, was there any particular reason why you 32-bit NetBSD? If there
> are none, can you please replace the VMs with 64-bit NetBSD. Until
> then you can keep mgmt_v3-locks.t disabled.
> 
> ~kaushal
> 
> On Tue, Apr 28, 2015 at 4:56 PM, Kaushal M  wrote:
>> I seem to have found the issue.
>> 
>> The uatomic_add_return function is defined in urcu/uatomic.h as
>> ```
>> /* uatomic_add_return */
>> 
>> static inline __attribute__((always_inline))
>> unsigned long __uatomic_add_return(void *addr, unsigned long val,
>>int len)
>> {
>>   switch (len) {
>>   case 1:
>>   {
>>   unsigned char result = val;
>> 
>>   __asm__ __volatile__(
>>   "lock; xaddb %1, %0"
>>   : "+m"(*__hp(addr)), "+q" (result)
>>   :
>>   : "memory");
>>   return result + (unsigned char)val;
>>   }
>>   case 2:
>>   {
>>   unsigned short result = val;
>> 
>>   __asm__ __volatile__(
>>   "lock; xaddw %1, %0"
>>   : "+m"(*__hp(addr)), "+r" (result)
>>   :
>>   : "memory");
>>   return result + (unsigned short)val;
>>   }
>>   case 4:
>>   {
>>   unsigned int result = val;
>> 
>>   __asm__ __volatile__(
>>   "lock; xaddl %1, %0"
>>   : "+m"(*__hp(addr)), "+r" (result)
>>   :
>>   : "memory");
>>   return result + (unsigned int)val;
>>   }
>> #if (CAA_BITS_PER_LONG == 64)
>>   case 8:
>>   {
>>   unsigned long result = val;
>> 
>>   __asm__ __volatile__(
>>   "lock; xaddq %1, %0"
>>   : "+m"(*__hp(addr)), "+r" (result)
>>   :
>>   : "memory");
>>   return result + (unsigned long)val;
>>   }
>> #endif
>>   }
>>   /*
>>* generate an illegal instruction. Cannot catch this with
>>* linker tricks when optimizations are disabled.
>>*/
>>   __asm__ __volatile__("ud2");
>>   return 0;
>> }
>> ```
>> 
>> As we can see, uatomic_add_return uses different assembly instructions
>> to perform the add based on the size of the datatype of the value. If
>> the size of the value doesn't exactly match one of the sizes in the
>> switch case, it deliberately generates a SIGILL.
>> 
>> The case for size 8, is conditionally compiled as we can see above.
>> From the backtrace Atin provided earlier, we see that the size of the
>> value is indeed 8 (we use uint64_t). Because we had a SIGILL, we can
>> conclude that the case for size 8 wasn't compiled.
>> 
>> I don't know why this compilation didn't (or as this is in a header
>> file, doesn't) happen on the NetBSD slaves and this is something I'd
>> like to find out.
>> 
>> ~kaushal
>> 
>> On Tue, Apr 28, 2015 at 1:50 PM, Anand Nekkunti  wrote:
>>> 
>>> On 04/28/2015 01:40 PM, Emmanuel Dreyfus wrote:
 
 On Tue, Apr 28, 2015 at 01:37:42PM +0530, Anand Nekkunti wrote:
> 
>__asm__ is for to write assembly code in c (gcc),
> __volatile__(:::)
> compiler level  barrier to force the compiler not to do reorder the
> instructions(to avoid optimization ) .
 
 Sure, but the gory details should be of no interest to the developer
 engaged in debug: if it crashes this is probably because it is called
 with wrong arguments, hence the question:
  ccing gluster-devel
>> 
>> new_peer->generation = uatomic_add_return (&conf->generation,
>> 1);
>> Are new_peer->generation and conf->generation sane?
>>> 
>>> 
>>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> http://www.gluster.org/mailman/listinfo/gluster-devel
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel

--
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-deve

Re: [Gluster-devel] Update on mgmt_v3-locks.t failure in netbsd

[Kaushal M]

Found the problem. The NetBSD slaves are running a 32-bit kernel and userspace.
```
nbslave7a# uname -p
i386
```

Because of this CAA_BITS_PER_LONG is set to 32 and the case for size 8
isn't compiled in uatomic_add_return. Even though the underlying
(virtual) hardware has 64-bit support, and supports the required
8-byte wide instrcution, it cannot be used because we are running on a
32-bit kernel with a 32-bit userspace.

Manu, was there any particular reason why you 32-bit NetBSD? If there
are none, can you please replace the VMs with 64-bit NetBSD. Until
then you can keep mgmt_v3-locks.t disabled.

~kaushal

On Tue, Apr 28, 2015 at 4:56 PM, Kaushal M  wrote:
> I seem to have found the issue.
>
> The uatomic_add_return function is defined in urcu/uatomic.h as
> ```
> /* uatomic_add_return */
>
> static inline __attribute__((always_inline))
> unsigned long __uatomic_add_return(void *addr, unsigned long val,
> int len)
> {
>switch (len) {
>case 1:
>{
>unsigned char result = val;
>
>__asm__ __volatile__(
>"lock; xaddb %1, %0"
>: "+m"(*__hp(addr)), "+q" (result)
>:
>: "memory");
>return result + (unsigned char)val;
>}
>case 2:
>{
>unsigned short result = val;
>
>__asm__ __volatile__(
>"lock; xaddw %1, %0"
>: "+m"(*__hp(addr)), "+r" (result)
>:
>: "memory");
>return result + (unsigned short)val;
>}
>case 4:
>{
>unsigned int result = val;
>
>__asm__ __volatile__(
>"lock; xaddl %1, %0"
>: "+m"(*__hp(addr)), "+r" (result)
>:
>: "memory");
>return result + (unsigned int)val;
>}
> #if (CAA_BITS_PER_LONG == 64)
>case 8:
>{
>unsigned long result = val;
>
>__asm__ __volatile__(
>"lock; xaddq %1, %0"
>: "+m"(*__hp(addr)), "+r" (result)
>:
>: "memory");
>return result + (unsigned long)val;
>}
> #endif
>}
>/*
> * generate an illegal instruction. Cannot catch this with
> * linker tricks when optimizations are disabled.
> */
>__asm__ __volatile__("ud2");
>return 0;
> }
> ```
>
> As we can see, uatomic_add_return uses different assembly instructions
> to perform the add based on the size of the datatype of the value. If
> the size of the value doesn't exactly match one of the sizes in the
> switch case, it deliberately generates a SIGILL.
>
> The case for size 8, is conditionally compiled as we can see above.
> From the backtrace Atin provided earlier, we see that the size of the
> value is indeed 8 (we use uint64_t). Because we had a SIGILL, we can
> conclude that the case for size 8 wasn't compiled.
>
> I don't know why this compilation didn't (or as this is in a header
> file, doesn't) happen on the NetBSD slaves and this is something I'd
> like to find out.
>
> ~kaushal
>
> On Tue, Apr 28, 2015 at 1:50 PM, Anand Nekkunti  wrote:
>>
>> On 04/28/2015 01:40 PM, Emmanuel Dreyfus wrote:
>>>
>>> On Tue, Apr 28, 2015 at 01:37:42PM +0530, Anand Nekkunti wrote:

 __asm__ is for to write assembly code in c (gcc),
 __volatile__(:::)
 compiler level  barrier to force the compiler not to do reorder the
 instructions(to avoid optimization ) .
>>>
>>> Sure, but the gory details should be of no interest to the developer
>>> engaged in debug: if it crashes this is probably because it is called
>>> with wrong arguments, hence the question:
>>>   ccing gluster-devel
>
>  new_peer->generation = uatomic_add_return (&conf->generation,
> 1);
> Are new_peer->generation and conf->generation sane?
>>
>>
>> ___
>> Gluster-devel mailing list
>> Gluster-devel@gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] glusterfs blocked.

[yang . bin18]

Hi,

I add some private function in dht_create() as bellow.

When current pwd is not "/",everything is ok,otherwise,syncop_getxattr 
will be blocked(In target subvol,"server3_3_getxatt" did not run  ).

 
dict_t *xattr = NULL; 
loc_t loc = {0, };
memset (loc.gfid, 0, 16);
loc.gfid[15] = 1;
ret = syncop_getxattr (subvol, &loc, 
&xattr,GF_XATTR_PATHINFO_KEY);

Best regards!

ZTE Information Security Notice: The information contained in this mail (and 
any attachment transmitted herewith) is privileged and confidential and is 
intended for the exclusive use of the addressee(s).  If you are not an intended 
recipient, any disclosure, reproduction, distribution or other dissemination or 
use of the information contained is strictly prohibited.  If you have received 
this mail in error, please delete it and notify us immediately.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Update on mgmt_v3-locks.t failure in netbsd

[Kaushal M]

I seem to have found the issue.

The uatomic_add_return function is defined in urcu/uatomic.h as
```
/* uatomic_add_return */

static inline __attribute__((always_inline))
unsigned long __uatomic_add_return(void *addr, unsigned long val,
int len)
{
   switch (len) {
   case 1:
   {
   unsigned char result = val;

   __asm__ __volatile__(
   "lock; xaddb %1, %0"
   : "+m"(*__hp(addr)), "+q" (result)
   :
   : "memory");
   return result + (unsigned char)val;
   }
   case 2:
   {
   unsigned short result = val;

   __asm__ __volatile__(
   "lock; xaddw %1, %0"
   : "+m"(*__hp(addr)), "+r" (result)
   :
   : "memory");
   return result + (unsigned short)val;
   }
   case 4:
   {
   unsigned int result = val;

   __asm__ __volatile__(
   "lock; xaddl %1, %0"
   : "+m"(*__hp(addr)), "+r" (result)
   :
   : "memory");
   return result + (unsigned int)val;
   }
#if (CAA_BITS_PER_LONG == 64)
   case 8:
   {
   unsigned long result = val;

   __asm__ __volatile__(
   "lock; xaddq %1, %0"
   : "+m"(*__hp(addr)), "+r" (result)
   :
   : "memory");
   return result + (unsigned long)val;
   }
#endif
   }
   /*
* generate an illegal instruction. Cannot catch this with
* linker tricks when optimizations are disabled.
*/
   __asm__ __volatile__("ud2");
   return 0;
}
```

As we can see, uatomic_add_return uses different assembly instructions
to perform the add based on the size of the datatype of the value. If
the size of the value doesn't exactly match one of the sizes in the
switch case, it deliberately generates a SIGILL.

The case for size 8, is conditionally compiled as we can see above.
>From the backtrace Atin provided earlier, we see that the size of the
value is indeed 8 (we use uint64_t). Because we had a SIGILL, we can
conclude that the case for size 8 wasn't compiled.

I don't know why this compilation didn't (or as this is in a header
file, doesn't) happen on the NetBSD slaves and this is something I'd
like to find out.

~kaushal

On Tue, Apr 28, 2015 at 1:50 PM, Anand Nekkunti  wrote:
>
> On 04/28/2015 01:40 PM, Emmanuel Dreyfus wrote:
>>
>> On Tue, Apr 28, 2015 at 01:37:42PM +0530, Anand Nekkunti wrote:
>>>
>>> __asm__ is for to write assembly code in c (gcc),
>>> __volatile__(:::)
>>> compiler level  barrier to force the compiler not to do reorder the
>>> instructions(to avoid optimization ) .
>>
>> Sure, but the gory details should be of no interest to the developer
>> engaged in debug: if it crashes this is probably because it is called
>> with wrong arguments, hence the question:
>>   ccing gluster-devel

  new_peer->generation = uatomic_add_return (&conf->generation,
 1);
 Are new_peer->generation and conf->generation sane?
>
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] REMINDER: Gluster Community Bug Triage meeting today at 12:00 UTC (in ~1 hour)

[Niels de Vos]

Hi all,

This meeting is scheduled for anyone that is interested in lssisting
with, or learning more about Bug Triage.

Meeting details:
- location: #gluster-meeting on Freenode IRC
( https://webchat.freenode.net/?channels=gluster-meeting )
- date: every Tuesday
- time: 12:00 UTC
(in your terminal, run: date -d "12:00 UTC")
- agenda: https://public.pad.fsfe.org/p/gluster-bug-triage

Currently the following items are listed:
* Roll Call
* Status of last weeks action items
* Group Triage
* Open Floor

The last two topics have space for additions. If you have a suitable bug
or topic to discuss, please add it to the agenda.

Thanks,
Niels
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Update on mgmt_v3-locks.t failure in netbsd

[Anand Nekkunti]

On 04/28/2015 01:40 PM, Emmanuel Dreyfus wrote:

On Tue, Apr 28, 2015 at 01:37:42PM +0530, Anand Nekkunti wrote:

__asm__ is for to write assembly code in c (gcc), __volatile__(:::)
compiler level  barrier to force the compiler not to do reorder the
instructions(to avoid optimization ) .

Sure, but the gory details should be of no interest to the developer
engaged in debug: if it crashes this is probably because it is called
with wrong arguments, hence the question:
  ccing gluster-devel

 new_peer->generation = uatomic_add_return (&conf->generation, 1);
Are new_peer->generation and conf->generation sane?


___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Update on mgmt_v3-locks.t failure in netbsd

[Atin Mukherjee]

On 04/28/2015 01:24 PM, Emmanuel Dreyfus wrote:
> On Tue, Apr 28, 2015 at 12:15:11PM +0530, Atin Mukherjee wrote:
>> I see netbsd regression doesn't execute peer probe from any other tests
>> apart from mgmt_v3-locks.t, if it had that would have also failed. So
>> the conclusion is peer probe doesn't work in netbsd.
> 
> It does not work anymore: that works in release-3.6, and it broke
> quite recently in master. 
> 
>> http://review.gluster.org/#/c/10147/ is the cause for it. I will
>> continue to investigate on this, however I am not able to understand
>> what this line __asm__ __volatile__("ud2") indicating. Any experts :) ?
> 
> This is the implementation for that in glusterd_peerinfo_new():
> new_peer->generation = uatomic_add_return (&conf->generation, 1);
> 
> Are new_peer->generation and conf->generation sane?
The expectation from the above statement is to execute
new_peer->generation = ++conf->generation atomically
> 

-- 
~Atin
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Update on mgmt_v3-locks.t failure in netbsd

[Emmanuel Dreyfus]

On Tue, Apr 28, 2015 at 12:15:11PM +0530, Atin Mukherjee wrote:
> I see netbsd regression doesn't execute peer probe from any other tests
> apart from mgmt_v3-locks.t, if it had that would have also failed. So
> the conclusion is peer probe doesn't work in netbsd.

It does not work anymore: that works in release-3.6, and it broke
quite recently in master. 

> http://review.gluster.org/#/c/10147/ is the cause for it. I will
> continue to investigate on this, however I am not able to understand
> what this line __asm__ __volatile__("ud2") indicating. Any experts :) ?

This is the implementation for that in glusterd_peerinfo_new():
new_peer->generation = uatomic_add_return (&conf->generation, 1);

Are new_peer->generation and conf->generation sane?

-- 
Emmanuel Dreyfus
m...@netbsd.org
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Update on mgmt_v3-locks.t failure in netbsd

[Niels de Vos]

On Tue, Apr 28, 2015 at 12:15:11PM +0530, Atin Mukherjee wrote:
> I see netbsd regression doesn't execute peer probe from any other tests
> apart from mgmt_v3-locks.t, if it had that would have also failed. So
> the conclusion is peer probe doesn't work in netbsd. Glusterd crashes
> with following bt when peer probe is executed:
> 
> #0  __uatomic_add_return (len=8, val=1, addr=) at
> /usr/pkg/include/urcu/uatomic.h:233
> 233 __asm__ __volatile__("ud2");
> (gdb) bt
> #0  __uatomic_add_return (len=8, val=1, addr=) at
> /usr/pkg/include/urcu/uatomic.h:233
> #1  glusterd_peerinfo_new (state=state@entry=GD_FRIEND_STATE_DEFAULT,
> uuid=uuid@entry=0x0,
> hostname=, hostname@entry=0xb8b040e0 "127.1.1.2",
> port=port@entry=24007)
> at glusterd-peer-utils.c:308
> #2  0xb91e0068 in glusterd_friend_add (hoststr=hoststr@entry=0xb8b040e0
> "127.1.1.2", port=port@entry=24007,
> state=state@entry=GD_FRIEND_STATE_DEFAULT, uuid=uuid@entry=0x0,
> friend=friend@entry=0xb89fff30,
> restore=restore@entry=_gf_false, args=args@entry=0xb89fff38) at
> glusterd-handler.c:3212
> #3  0xb91e2927 in glusterd_probe_begin (req=req@entry=0xb8f40040,
> hoststr=0xb8b040e0 "127.1.1.2", port=24007,
> dict=0xb9c013b0, op_errno=op_errno@entry=0xb89fff9c) at
> glusterd-handler.c:3320
> #4  0xb91e2de2 in __glusterd_handle_cli_probe (req=0xb8f40040) at
> glusterd-handler.c:1078
> #5  0xb91dc932 in glusterd_big_locked_handler (req=req@entry=0xb8f40040,
> actor_fn=actor_fn@entry=0xb91e294d <__glusterd_handle_cli_probe>) at
> glusterd-handler.c:83
> #6  0xb91dc9e8 in glusterd_handle_cli_probe (req=0xb8f40040) at
> glusterd-handler.c:1105
> #7  0xbb787c82 in synctask_wrap (old_task=0xb8f66000) at syncop.c:375
> #8  0xbb39c630 in ?? () from /usr/lib/libc.so.12
> 
> http://review.gluster.org/#/c/10147/ is the cause for it. I will
> continue to investigate on this, however I am not able to understand
> what this line __asm__ __volatile__("ud2") indicating. Any experts :) ?

IIRC, the Linux kernel executes this when a BUG() statement is hit and
logging or a kernel panic should happen.

You probably need someone that understands userspace-rcu to get an
understanding of when/how "ud2" is used there.

HTH,
Niels


pgpyatlOhqZfS.pgp
Description: PGP signature
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel