I have narrowed down the source of the bug.
Here is an strace of glusterfsd http://fpaste.org/131455/40996378/
The first line represents a write that does *not* make it into the underlying
file.
The last line is the write that stomps the earlier write.
As I said, the client file is opened in
On 06/09/2014, at 12:10 AM, mike wrote:
> I have found that the O_APPEND flag is key to this failure - I had overlooked
> that flag when reading the strace and trying to cobble up a minimal
> reproduction.
>
> I now have a small pair of python scripts that can reliably reproduce this
> failure.
> Thanks Jeff for the detailed explanation. You mentioned delayed changelog may
> have prevented this issue. Can you please tell me how to enable it?
It's on by default (cluster.post-op-delay-secs in the CLI) with a value of 1.
However, it's inoperative in some cases, such as when multiple fds ar
Thanks Jeff for the detailed explanation. You mentioned delayed changelog may
have prevented this issue. Can you please tell me how to enable it?
Thanks
Ramesh
On Sep 5, 2014, at 6:23 PM, Jeff Darcy wrote:
>> I have a replicate glusterfs setup on 3 Bricks ( replicate = 3 ). I have
>> client
> I have a replicate glusterfs setup on 3 Bricks ( replicate = 3 ). I have
> client and server quorum turned on. I rebooted one of the 3 bricks. When it
> came back up, the client started throwing error messages that one of the
> files went into split brain.
This is a good example of how split bra
I have found that the O_APPEND flag is key to this failure - I had overlooked
that flag when reading the strace and trying to cobble up a minimal
reproduction.
I now have a small pair of python scripts that can reliably reproduce this
failure.
On Sep 5, 2014, at 11:11 AM, mike wrote:
> Hi al
> Does this mean we'll need to learn Go as well as C and Python?
>
> If so, that doesn't sound completely optimal. :/
>
> That being said, a lot of distributed/networked computing
> projects seem to be written in it these days. Is Go specifically
> a good language for our kind of challenges, or is
On 2014-09-04 16:31, Kaleb KEITHLEY wrote:
> On 09/04/2014 06:18 PM, Ernie Dunbar wrote:
>
>> Hi, I just started using Gluster today to build a new fileserver, and so far
>> I'm impressed with the ease of set-up and configuration. However, my cluster
>> appears to be working normally, yet n
I have a replicate glusterfs setup on 3 Bricks ( replicate = 3 ). I have
client and server quorum turned on. I rebooted one of the 3 bricks. When
it came back up, the client started throwing error messages that one of the
files went into split brain.
When i check the file sizes and sha1sum on the
Hi all,
I've been trying to track down a bug that looks like data corruption coming
from the Gluster FUSE client. I'm pretty new to Gluster, so perhaps there are
better ways to get to the bottom of this.
I have a distributed, replicated volume that was initialized as 3.5.1 and it
has been func
___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users
Hi Justin,
Regarding the server.py script, yes that graph is live and it is refreshed
periodically. According to the model right now, the server script at the
backend polls the meta directory of mounted volumes repeatedly, calculates the
speed from the difference of values encountered and sto
On Wed, Sep 03, 2014 at 09:00:09PM +0530, M S Vishwanath Bhat wrote:
> On 03/09/14 20:31, David F. Robinson wrote:
> >Is this bug-fix going to be in the 3.5.3 beta release?
> Not sure. I will have to check that. AFAIK the patches are present in
> upstream and 3.6 branch. Is upgrading to 3.6 an opti
> As part of the first phase, we aim to delegate the distributed configuration
> store. We are exploring consul [1] as a replacement for the existing
> distributed configuration store (sum total of /var/lib/glusterd/* across all
> nodes). Consul provides distributed configuration store which is con
> Isn't some of this covered by crm/corosync/pacemaker/heartbeat?
Sorta, kinda, mostly no. Those implement virtual synchrony, which is
closely related to consensus but not quite the same even in a formal CS
sense. In practice, using them is *very* different. Two jobs ago, I
inherited a design b
Libvirt log does not contain anything related. The error messages go
from dmesg of virtual machine.
What I can see in gluster logs is that connection between two peers was
lost. The physical connection, however, worked all the time.
Dne 5.9.2014 0:47, Joe Julian napsal(a):
That is about as fa
Hi,
consider looking at this topic
http://supercolony.gluster.org/pipermail/gluster-users/2014-September/018577.html
. This guy made lots of test. It seems like 50 MB/s (or around 400 Mbps) is
the theoretical maximal limit for replica 1. I am waiting for comments to
this too.
2014-09-05 11:15 GM
- Original Message -
> On 5 Sep 2014, at 12:21, Kaushal M < kshlms...@gmail.com > wrote:
>
>
>
> - Peer membership management
> - Maintains consistency of configuration data across nodes (distributed
> configuration store)
> - Distributed command execution (orchestration)
> - Service m
- Original Message -
> On 05/09/2014, at 11:21 AM, Kaushal M wrote:
>
> > As part of the first phase, we aim to delegate the distributed
> > configuration store. We are exploring consul [1]
>
> Does this mean we'll need to learn Go as well as C and Python?
>
> If so, that doesn't sound
On 5 Sep 2014, at 12:21, Kaushal M wrote:
> - Peer membership management
> - Maintains consistency of configuration data across nodes (distributed
> configuration store)
> - Distributed command execution (orchestration)
> - Service management (manage GlusterFS daemons)
> - Portmap service for Gl
On 05/09/2014, at 11:21 AM, Kaushal M wrote:
> As part of the first phase, we aim to delegate the distributed configuration
> store. We are exploring consul [1]
Does this mean we'll need to learn Go as well as C and Python?
If so, that doesn't sound completely optimal. :/
That being said, a l
On 09/04/2014 10:45 PM, Pranith Kumar Karampuri wrote:
On 09/04/2014 10:34 PM, John Mark Walker wrote:
Thanks Pranith - has a bug been filed so we can track this?
https://bugzilla.redhat.com/show_bug.cgi?id=1138386
Bug is happening because of synchronization problem between 'distribute'
xlat
GlusterD performs the following functions as the management daemon for
GlusterFS:
- Peer membership management
- Maintains consistency of configuration data across nodes (distributed
configuration store)
- Distributed command execution (orchestration)
- Service management (manage GlusterFS daemons)
Funny you mention this, yesterday i enable the worm feature for the first time
and i noticed this too :) I was already frightened that my whole setup was
broken!
Good to know it's a known problem, it's not blocking us in any way...
Thanks!
-Original Message-
From: Atin Mukherjee [mailto:
Hi all：
I do the following test：
I create a glusterfs replica volume (replica count is 2 ) with two server
node(server A and server B)， then mount the volume in client node，
then， I shut down the network of server A node， in client node， I copy a
dir（which has a lot of small f
25 matches
Mail list logo
