Re: add/replace brick corrupting data

[WK <wkmail@xxxxxxxxx>]

That should be an important clue.

That being said, when we lose a brick, we've traditionally just live migrated those VMs off onto other clusters because we didn't want to take the heal hit which at best slowed down our VMs at on the pickier ones cause them to RO out.

We have not yet upgraded to 3.7.x yet (still on 3.4 cuz it aint broke) and are hoping that sharding solves that problem.  But it seems everytime it looks like things are 'safe' for 3.7.x, something comes up. Fortunately, we like the fuse mount so maybe we are still ok.

-wk

On 5/16/2016 4:42 AM, Lindsay Mathieson wrote:

Ok, this is probably an interesting data point. I was unable to reproduce the problem when using the fuse mount.

Its late here so I might not have time to repeat with the gfapi, but I will tomorrow.


On 16/05/2016 4:55 PM, Krutika Dhananjay wrote:

Yes, that would probably be useful in terms of at least having access to the client logs.

-Krutika

On Mon, May 16, 2016 at 12:18 PM, Lindsay Mathieson <lindsay.mathieson@xxxxxxxxx> wrote:

On 16 May 2016 at 16:46, Krutika Dhananjay <kdhananj@xxxxxxxxxx> wrote:
> Could you share the mount and glustershd logs for investigation?


Can do, though its via gfapi rather than the fuse mount.

If I can replicate the problem off the fuse mount would that be more useful?

--
Lindsay

-- 
Lindsay Mathieson

_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users

_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users