Re: File Corruption with shards - 100% reproducable

[Krutika Dhananjay <kdhananj@xxxxxxxxxx>]

OK. What do the client logs say?

Could you share the exact steps to recreate this, and I will try it locally on my setup?

Also, want to see the output of 'gluster volume info'.

-Krutika

---

From: "Lindsay Mathieson" <lindsay.mathieson@xxxxxxxxx>
To: "Krutika Dhananjay" <kdhananj@xxxxxxxxxx>
Cc: "gluster-users" <gluster-users@xxxxxxxxxxx>
Sent: Thursday, November 12, 2015 11:04:51 AM
Subject: Re: File Corruption with shards - 100% reproducable

On 5 November 2015 at 21:55, Krutika Dhananjay <kdhananj@xxxxxxxxxx> wrote:

Although I do not have experience with VM live migration,  IIUC, it is got to do with a different server (and as a result a new glusterfs client process) taking over the operations and mgmt of the VM.

If this is a correct assumption, then I think this could be the result of the same caching bug that I talked about sometime back in 3.7.5, which is fixed in 3.7.6.

The issue could cause the new client to not see the correct size and block count of the file, leading to errors in reads (perhaps triggered by the restart of the vm) and writes on the image.

Unfortunately this problem is still occuring with 3.7.6, 100% of the time.

Tried with shards disabled and there no problem.

--

Lindsay

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