Re: [Gluster-devel] Throttling xlator on the bricks

On 01/25/16 18:24, Ravishankar N wrote: On 01/26/2016 01:22 AM, Shreyas Siravara wrote: Just out of curiosity, what benefits do we think this throttling xlator would provide over the "enable-least-priority" option (where we put all the fops from SHD, etc into a least pri queue)? For

Re: [Gluster-devel] Throttling xlator on the bricks

On 01/26/2016 08:14 AM, Vijay Bellur wrote: On 01/25/2016 12:36 AM, Ravishankar N wrote: Hi, We are planning to introduce a throttling xlator on the server (brick) process to regulate FOPS. The main motivation is to solve complaints about AFR selfheal taking too much of CPU resources. (due

Re: [Gluster-devel] distributed files/directories and [cm]time updates

Hi Pranith, On 26/01/16 03:47, Pranith Kumar Karampuri wrote: hi, Traditionally gluster has been using ctime/mtime of the files/dirs on the bricks as stat output. Problem we are seeing with this approach is that, software which depends on it gets confused when there are differences in

Re: [Gluster-devel] Throttling xlator on the bricks

On Tue, Jan 26, 2016 at 03:11:50AM +, Richard Wareing wrote: > > If there is one bucket per client and one thread per bucket, it would be > > difficult to scale as the number of clients increase. How can we do this > > better? > > On this note... consider that 10's of thousands of clients are

Re: [Gluster-devel] [Gluster-infra] Smoke tests run on the builder in RH DC (at least)

Le lundi 25 janvier 2016 à 22:24 +0100, Niels de Vos a écrit : > On Mon, Jan 25, 2016 at 06:59:33PM +0100, Michael Scherer wrote: > > Hi, > > > > so today, after fixing one last config item, the smoke test jobs run > > fine on the Centos 6 builder in the RH DC, which build things as non > > root,

Re: [Gluster-devel] Throttling xlator on the bricks

On 01/25/16 20:36, Pranith Kumar Karampuri wrote: On 01/26/2016 08:41 AM, Richard Wareing wrote: If there is one bucket per client and one thread per bucket, it would be difficult to scale as the number of clients increase. How can we do this better? On this note... consider that 10's of

Re: [Gluster-devel] Tips and Tricks for Gluster Developer

On Mon, Jan 25, 2016 at 06:41:50AM -0500, Rajesh Joseph wrote: > > > - Original Message - > > From: "Richard Wareing" > > To: "Raghavendra Talur" > > Cc: "Gluster Devel" > > Sent: Monday, January 25, 2016 8:12:53 AM > >

Re: [Gluster-devel] Tips and Tricks for Gluster Developer

- Original Message - From: "Jeff Darcy" To: "Richard Wareing" Cc: "Gluster Devel" Sent: Monday, January 25, 2016 7:27:20 PM Subject: Re: [Gluster-devel] Tips and Tricks for Gluster Developer Oh boy, here we go. ;) I

Re: [Gluster-devel] Tips and Tricks for Gluster Developer

- Original Message - > From: "Niels de Vos" > To: "Rajesh Joseph" > Cc: "Richard Wareing" , "Gluster Devel" > > Sent: Monday, January 25, 2016 6:30:53 PM > Subject: Re: [Gluster-devel] Tips and Tricks

[Gluster-devel] Gerrit down for 10 to 15 minutes for reindexing

Hi, in order to fix some issues (I hope), I am gonna start a reindex of the lucense DB of gerrit. This requires the server to be put offline for a while, and I did a test on another VM, would take ~10 minutes (it was 240 seconds on the VM, but it was likely faster since the VM is faster) I will

Re: [Gluster-devel] Tips and Tricks for Gluster Developer

Oh boy, here we go. ;) I second Richard's suggestion to use cscope or some equivalent. It's a good idea in general, but especially with a codebase as large and complex as Gluster's. I literally wouldn't be able to do my job without it. I also have a set of bash/zsh aliases that will

Re: [Gluster-devel] Smoke tests run on the builder in RH DC (at least)

On Mon, Jan 25, 2016 at 11:29 PM, Michael Scherer wrote: > Hi, > > so today, after fixing one last config item, the smoke test jobs run > fine on the Centos 6 builder in the RH DC, which build things as non > root, then start the tests, then reboot the server. > Awesome!

Re: [Gluster-devel] Throttling xlator on the bricks

Just out of curiosity, what benefits do we think this throttling xlator would provide over the "enable-least-priority" option (where we put all the fops from SHD, etc into a least pri queue)? > On Jan 25, 2016, at 12:29 AM, Venky Shankar wrote: > > On Mon, Jan 25, 2016

Re: [Gluster-devel] [Gluster-users] Gluster Monthly Newsletter, January 2015 Edition

On Fri, Jan 22, 2016 at 9:29 AM, Niels de Vos wrote: > On Mon, Jan 18, 2016 at 07:46:16PM -0800, Amye Scavarda wrote: >> We're kicking off an updated Monthly Newsletter, coming out mid-month. >> We'll highlight special posts, news and noteworthy threads from the >> mailing

Re: [Gluster-devel] [Gluster-users] Memory leak in GlusterFS FUSE client

Here are the results of "rsync" test. I've got 2 volumes — source and target — performing multiple files rsyncing from one volume to another. Source volume: === root 22259 3.5 1.5 1204200 771004 ? Ssl Jan23 109:42 /usr/sbin/ glusterfs --volfile-server=glusterfs.example.com

Re: [Gluster-devel] Gerrit down for 10 to 15 minutes for reindexing

Le lundi 25 janvier 2016 à 15:41 +0100, Michael Scherer a écrit : > Hi, > > in order to fix some issues (I hope), I am gonna start a reindex of the > lucense DB of gerrit. This requires the server to be put offline for a > while, and I did a test on another VM, would take ~10 minutes (it was >

[Gluster-devel] Smoke tests run on the builder in RH DC (at least)

Hi, so today, after fixing one last config item, the smoke test jobs run fine on the Centos 6 builder in the RH DC, which build things as non root, then start the tests, then reboot the server. Now, I am looking at the fedora one, but once this one is good, I will likely reinstall a few builders

Re: [Gluster-devel] [Gluster-infra] Smoke tests run on the builder in RH DC (at least)

On Mon, Jan 25, 2016 at 06:59:33PM +0100, Michael Scherer wrote: > Hi, > > so today, after fixing one last config item, the smoke test jobs run > fine on the Centos 6 builder in the RH DC, which build things as non > root, then start the tests, then reboot the server. Nice, sounds like great

Re: [Gluster-devel] Feature: Automagic lock-revocation for features/locks xlator (v3.7.x)

Hey Hey Panith, >Maybe give clients a second (or more) chance to "refresh" their locks - in the >sense, when a lock is about to be revoked, notify the client which can then >call for a refresh to conform it's locks holding validity. This would require >some maintainance work on the client to

Re: [Gluster-devel] [Gluster-infra] Smoke tests run on the builder in RH DC (at least)

On Mon, Jan 25, 2016 at 10:24:33PM +0100, Niels de Vos wrote: > On Mon, Jan 25, 2016 at 06:59:33PM +0100, Michael Scherer wrote: > > Hi, > > > > so today, after fixing one last config item, the smoke test jobs run > > fine on the Centos 6 builder in the RH DC, which build things as non > > root,

Re: [Gluster-devel] Tips and Tricks for Gluster Developer

On 01/22/2016 09:13 AM, Raghavendra Talur wrote: HI All, I am sure there are many tricks hidden under sleeves of many Gluster developers. I realized this when speaking to new developers. It would be good have a searchable thread of such tricks. Just reply back on this thread with the tricks

[Gluster-devel] Vault CFP closes January 29th

The Linux Foundation's Vault (http://events.linuxfoundation.org/events/vault ) event focusing on Linux storage and filesystems currently has their call for papers open - but it closes this Friday, January 29th. I'm highlighting this because GlusterFS is mentioned as a suggested topic! This year,

Re: [Gluster-devel] Throttling xlator on the bricks

On Mon, Jan 25, 2016 at 01:08:38PM +0530, Ravishankar N wrote: > On 01/25/2016 12:56 PM, Venky Shankar wrote: > >Also, it would be beneficial to have the core TBF implementation as part of > >libglusterfs so as to be consumable by the server side xlator component to > >throttle dispatched FOPs and

Re: [Gluster-devel] [Gluster-users] GlusterFS FUSE client hangs on rsyncing lots of file

the client statedump is at http://pastebin.centos.org/38671/ On Mon, Jan 25, 2016 at 3:33 PM, baul jianguo wrote: > 3.5.7 also hangs.only the flush op hung. Yes,off the > performance.client-io-threads ,no hang. > > The hang does not relate the client kernel version. > > One

Re: [Gluster-devel] Tips and Tricks for Gluster Developer

I don't like installing the bits under /usr/local so I configure and compile them to install in the same place as a Fedora rpm would. Here is my compile command ./autogen.sh CFLAGS="-g -O0 -Werror -Wall -Wno-error=cpp -Wno-error=maybe-uninitialized" ./configure \ --prefix=/usr \

Re: [Gluster-devel] Tips and Tricks for Gluster Developer

- Original Message - > From: "Richard Wareing" > To: "Raghavendra Talur" > Cc: "Gluster Devel" > Sent: Monday, January 25, 2016 8:12:53 AM > Subject: Re: [Gluster-devel] Tips and Tricks for Gluster Developer > > Here's my

Re: [Gluster-devel] Throttling xlator on the bricks

On 01/26/2016 01:22 AM, Shreyas Siravara wrote: Just out of curiosity, what benefits do we think this throttling xlator would provide over the "enable-least-priority" option (where we put all the fops from SHD, etc into a least pri queue)? For one, it could provide more granularity on

Re: [Gluster-devel] Throttling xlator on the bricks

On 01/25/2016 12:36 AM, Ravishankar N wrote: Hi, We are planning to introduce a throttling xlator on the server (brick) process to regulate FOPS. The main motivation is to solve complaints about AFR selfheal taking too much of CPU resources. (due to too many fops for entry self-heal, rchecksums

[Gluster-devel] distributed files/directories and [cm]time updates

hi, Traditionally gluster has been using ctime/mtime of the files/dirs on the bricks as stat output. Problem we are seeing with this approach is that, software which depends on it gets confused when there are differences in these times. Tar especially gives "file changed as we read it"

Re: [Gluster-devel] Throttling xlator on the bricks

> If there is one bucket per client and one thread per bucket, it would be > difficult to scale as the number of clients increase. How can we do this > better? On this note... consider that 10's of thousands of clients are not unrealistic in production :). Using a thread per bucket would also