Here goes the report on DHT-related leaks patch ("rsync" test).
RAM usage before drop_caches: [1]
Statedump before drop_caches: [2]
RAM usage after drop_caches: [3]
Statedump after drop_caches: [4]
Statedumps diff: [5]
Valgrind output: [6]
[1] https://gist.github.com/ca8d56834c14c4bfa98e
[2] htt
Hi Kris,
These failures are mostly while transferring data from Master to Slave.
Geo-replication is not intelligent to find exact number and reason for
failures. I sent patch to effectively handle the rsync/tar failures.
This patch is expected to be available with 3.7.8 release.
http://review
On 01/27/2016 12:49 PM, Atin Mukherjee wrote:
>
>
> On 01/27/2016 12:40 PM, Pranith Kumar Karampuri wrote:
>>
>>
>> On 01/27/2016 09:21 AM, Atin Mukherjee wrote:
>>>
>>> On 01/27/2016 07:21 AM, Vijay Bellur wrote:
On 01/26/2016 01:19 PM, Marc Eisenbarth wrote:
> I'm trying to set a par
I recently setup geo-replication between two sites, and everything appears to
be working, however, if I do a "gluster volume geo-replication SourceVol
DestVol status detail", I see that the "failures" column seems to be
incrementing for each file it transfers. I've looked at the logs in
/var/
On 01/30/2016 09:35 AM, Kaushal M wrote:
> Hi,
>
> Apologies for the late announcement. glusterfs-3.6.8 was tagged and
> released on 7th Jan.
>
> The tarball and packages for your favorite distributions can be
> obtained from http://download.gluster.org/pub/gluster/glusterfs/3.6/3.6.8/
>
> Regard
Not historically, but we are using bonding for replication between the
servers. It's been stable for at least 6 months, but it's possible that
one of the links in the bond is failing or something.
Would this type of restart be triggered by a loss of communication between
bricks in a replica set?
On Fri, 2016-01-15 at 11:17 +0100, Niels de Vos wrote:
> On Thu, Jan 14, 2016 at 11:53:28PM +, Kingsley wrote:
> > On Thu, 2016-01-14 at 13:13 +0100, Niels de Vos wrote:
> > > Yes, RHEL updated the Gluster packages to 3.7.x. What you see here might
> > > be from an attempt to update the gluste
- Original Message -
> From: "Serkan Çoban"
>
> Will those patches be available in 3.7.7?
3.7.7 was released yesterday, so no.
But 3.7.7 has another issue; there won't be packages available from
download.gluster.org.
Pranith has already indicated that we will fix the other issue and
Hello,
Sorry for not replying, but lately the issue cannot be reproduced. If we have
any new occurrences I’ll collect the logs and send them here.
Klearchos
From: EXT Krutika Dhananjay [mailto:kdhan...@redhat.com]
Sent: Wednesday, January 27, 2016 7:12 AM
To: Chaloulos, Klearchos (Nokia - GR/At
Hi,
Thanks Anoop for the help,
Would you please tell me when can we expect this new release with this bug
fix.
Thanks & Reagrds
On Fri, Jan 29, 2016 at 12:42 PM, Anoop C S wrote:
> On Wed, 2016-01-27 at 15:25 +0530, PankaJ Singh wrote:
> >
> > Hi,
> >
> > We are using gluster 3.7.6 on ubunt
02.02.2016 10:07, Xavier Hernandez написав:
Could it be memory used by Valgrind itself to track glusterfs' memory
usage ?
Could you repeat the test without Valgrind and see if the memory usage
after dropping caches returns to low values ?
Yup. Here are the results:
===
pf@server:~ » ps aux |
Hi all,
The Gluster Community Bug Triage Meeting for today is canceled because of less
number of participants. Expecting more participants for next week's bug triage
meeting.
--
Thanks & Regards,
Manikandan Selvaganesh.
- Original Message -
From: "Manikandan Selvaganesh"
To: "Gluster D
Hi all,
This meeting is scheduled for anyone that is interested in learning more
about, or assisting with the Bug Triage.
Meeting details:
- location: #gluster-meeting on Freenode IRC
(https://webchat.freenode.net/?channels=gluster-meeting )
- date: every Tuesday
- time: 12:00 UTC
Hi Oleksandr,
On 01/02/16 19:28, Oleksandr Natalenko wrote:
Please take a look at updated test results.
Test: find /mnt/volume -type d
RAM usage after "find" finishes: ~ 10.8G (see "ps" output [1]).
Statedump after "find" finishes: [2].
Then I did drop_caches, and RAM usage dropped to ~4.7G
14 matches
Mail list logo