On Wed, Jul 16, 2014 at 09:54:49PM -0700, Harshavardhana wrote:
In-fact this is true on Linux as well - there is smaller time window
observe the below output , immediately run 'volume status' after a
'volume start' event
I observe the same lapse on NetBSD if the volume is created and started.
On a side note while looking into this issue - I uncovered a memory
leak too which after successful registration with glusterd, Self-heal
daemon and NFS server are killed by FreeBSD memory manager. Have you
observed any memory leaks?
I have the valgrind output and it clearly indicates of large
Emmanuel,
Could you take statedump* of the glustershd process when it has leaked
enough memory to be able to observe and share the output? This might
give us what kind of objects are we allocating abnormally high.
* statedump of a glusterfs process
#kill -USR1 pid of process
HTH,
Krish
KP,
I do have a 3.2Gigs worth of valgrind output which indicates this
issue, trying to reproduce this on Linux.
My hunch says that 'compiling' with --disable-epoll might actually
trigger this issue on Linux too. Will update here
once i have done that testing.
On Wed, Jul 16, 2014 at 11:44 PM,
Harsha,
In addition to the valgrind output, statedump output of glustershd process when
the leak is observed would be really helpful.
thanks,
Krish
- Original Message -
Nope spoke too early, using poll() has no effect on the memory usage
on Linux, so actually back to FreeBSD.
On
On 07/15/2014 04:39 PM, Pranith Kumar Karampuri wrote:
hi,
Please respond if you guys volunteer to add documentation for
any of the following things that are not already taken.
client_t - pranith
integration with statedump - pranith
mempool - Pranith
event-hostory + circ-buff -
...and I'm sorry about that, the following documents are somewhat contradictory:
http://gluster.org/community/documentation/index.php/Simplified_dev_workflow
The script will ask you to enter a bugzilla bug id. Every
change submitted to GlusterFS needs a bugzilla entry to be
accepted. If you
I don't understand your confusion, but maybe these docs need to be reworded.
What both of these want to say is that for a patch to be merged into
glusterfs, it needs to be associated with a bug-id. This association
is done by adding a 'BUG: id' line in the commit message. If you
haven't manually
On 2014-07-17 15:44, Kaushal M wrote:
I don't understand your confusion, but maybe these docs need to be reworded.
Not confused, just observed that some of my patches regarding development
workflow does not need to show up as bugs for gluster (at least not until
somebody has verified that they
Bugs/bug in the documents are not really what you think they mean.
We use bugzilla to track glusterfs development. It is used for track
defects (bugs) in the software, enhancements and new features. What we
really mean by a patch needs a bug id is that we need it to have an
entry on bugzilla, so
This is a small memory system like 1024M and a disk space for the
volume is 9gig, i do not think it has anything to do with AFR per se -
same bug is also reproducible on the bricks, nfs server too. Also it
might be that we aren't able to capture glusterdumps on non Linux
platforms properly - one
Hi All,
A new branch, 'release-3.6', has been branched from this commit in master:
commit 950f9d8abe714708ca62b86f304e7417127e1132
Author: Jeff Darcy jda...@redhat.com
Date: Tue Jul 8 21:56:04 2014 -0400
dht: fix rename race
You can checkout this branch through:
$git checkout -b
What impact, if any, does starting profiling (gluster volume profile
$vol start) have on performance?
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Anyone?
On Mon, Jul 14, 2014 at 6:44 PM, Harshavardhana
har...@harshavardhana.net wrote:
http://review.gluster.org/#/c/8246/
Two important things it achieves
- Break-way from '/var/lib/glusterd' hard-coded previously,
instead rely on 'configure' value from 'localstatedir'
- Provide
- Original Message -
| From: Eco Willson ewill...@redhat.com
| To: Justin Clift jus...@gluster.org
| Cc: Gluster Devel gluster-devel@gluster.org, Humble Chirammal
hchir...@redhat.com
| Sent: Thursday, July 17, 2014 5:32:13 AM
| Subject: Re: [Gluster-devel] Updating blog entry list on
On 07/18/2014 03:05 AM, Joe Julian wrote:
What impact, if any, does starting profiling (gluster volume profile
$vol start) have on performance?
Joe,
According to the code the only extra things it does is calling
gettimeofday() call at the beginning and end of the FOP to calculate
On 17/07/2014, at 7:38 PM, Vijay Bellur wrote:
snip
Had a discussion with Pranith and we felt that 3.5.2 beta is of
more importance than 3.6 community test days.
Definitely agree personally. People have 3.5.x in production, so
to my thinking issues with that should receive priority. 3.6 will
Harsha,
I haven't gotten around looking at the valgrind output. I am not sure if I will
be able to do it soon since I am travelling next week.
Are you seeing an equal no. of disconnect messages in glusterd logs? What is
the ip:port you observe in the RPC_CLNT_CONNECT messages? Could you attach
Sure will do that! - if i get any clues i might send out a patch :-)
On Thu, Jul 17, 2014 at 9:05 PM, Krishnan Parthasarathi
kpart...@redhat.com wrote:
Harsha,
I haven't gotten around looking at the valgrind output. I am not sure if I
will be able to do it soon since I am travelling next
On 07/17/2014 07:25 PM, Kaushal M wrote:
I came across mediawiki's developer documentation and guides when
browsing. These docs felt really good to me, and easy to approach.
I feel that we should take inspiration from them and start enhancing
our docs. (Outright copying with modifications as
On Fri, Jul 18, 2014 at 11:11 AM, Pranith Kumar Karampuri
pkara...@redhat.com wrote:
On 07/17/2014 07:25 PM, Kaushal M wrote:
I came across mediawiki's developer documentation and guides when
browsing. These docs felt really good to me, and easy to approach.
I feel that we should take
21 matches
Mail list logo
