I have two separate cluster, with this problem, the output of "dlm_tool ls" on other site is: dlm_tool ls dlm lockspaces name VMStorage4 id 0xfd25ae65 flags 0x00000008 fs_reg change member 2 joined 0 remove 1 failed 1 seq 2,2 members 2 3 name VMStorage3 id 0xb26438a2 flags 0x00000008 fs_reg change member 2 joined 0 remove 1 failed 1 seq 2,2 members 2 3 name VMStorage2 id 0xab7f09e3 flags 0x00000008 fs_reg change member 2 joined 0 remove 1 failed 1 seq 2,2 members 2 3 name VMStorage1 id 0x80525a20 flags 0x00000008 fs_reg change member 2 joined 0 remove 1 failed 1 seq 2,2 members 2 3 There is one fail ....!!!! On Thu, Jan 29, 2015 at 1:16 PM, cluster lab <cluster.labs@xxxxxxxxx> wrote: > Node2 # touch /VMStorage1/test > > Node1 # ls /VMStorage1/test > /VMStorage1/test > Node1 # rm /VMStorage1/test > rm: remove regular empty file `/VMStorage1/test'? y > > ==== > > Node1 # touch /VMStorage1/test > > Node2 # ls /VMStorage1/test > /VMStorage1/test > Node2 # rm /VMStorage1/test > rm: remove regular empty file `/VMStorage1/test'? y > > No Problem .... > > On Thu, Jan 29, 2015 at 9:25 AM, Digimer <lists@xxxxxxxxxx> wrote: >> That looks OK. Can you touch a file from one node and see it on the other >> and vice-versa? Is there anything in either node's log files when you run >> 'qemu-img check'? >> >> >> On 29/01/15 12:34 AM, cluster lab wrote: >>> >>> Node2: # dlm_tool ls >>> dlm lockspaces >>> name VMStorage3 >>> id 0xb26438a2 >>> flags 0x00000008 fs_reg >>> change member 2 joined 1 remove 0 failed 0 seq 1,1 >>> members 1 2 >>> >>> name VMStorage2 >>> id 0xab7f09e3 >>> flags 0x00000008 fs_reg >>> change member 2 joined 1 remove 0 failed 0 seq 1,1 >>> members 1 2 >>> >>> name VMStorage1 >>> id 0x80525a20 >>> flags 0x00000008 fs_reg >>> change member 2 joined 1 remove 0 failed 0 seq 1,1 >>> members 1 2 >>> =========================================== >>> Node1: # dlm_tool ls >>> dlm lockspaces >>> name VMStorage3 >>> id 0xb26438a2 >>> flags 0x00000008 fs_reg >>> change member 2 joined 1 remove 0 failed 0 seq 2,2 >>> members 1 2 >>> >>> name VMStorage2 >>> id 0xab7f09e3 >>> flags 0x00000008 fs_reg >>> change member 2 joined 1 remove 0 failed 0 seq 2,2 >>> members 1 2 >>> >>> name VMStorage1 >>> id 0x80525a20 >>> flags 0x00000008 fs_reg >>> change member 2 joined 1 remove 0 failed 0 seq 2,2 >>> members 1 2 >>> >>> On Thu, Jan 29, 2015 at 8:57 AM, Digimer <lists@xxxxxxxxxx> wrote: >>>> >>>> On 28/01/15 11:50 PM, cluster lab wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> In a two node cluster, i received to different result from "qemu-img >>>>> check" on just one file: >>>>> >>>>> node1 # qemu-img check VMStorage/x.qcow2 >>>>> No errors were found on the image. >>>>> >>>>> Node2 # qemu-img check VMStorage/x.qcow2 >>>>> qemu-img: Could not open 'VMStorage/x.qcow2" >>>>> >>>>> All other files are OK, and the cluster works properly. >>>>> What is the problem? >>>>> >>>>> ==== >>>>> Packages: >>>>> kernel: 2.6.32-431.5.1.el6.x86_64 >>>>> GFS2: gfs2-utils-3.0.12.1-23.el6.x86_64 >>>>> corosync: corosync-1.4.1-17.el6.x86_64 >>>>> >>>>> Best Regards >>>> >>>> >>>> >>>> What does 'dlm_tool ls' show? >>>> >>>> -- >>>> Digimer >>>> Papers and Projects: https://alteeve.ca/w/ >>>> What if the cure for cancer is trapped in the mind of a person without >>>> access to education? >>>> >>>> -- >>>> Linux-cluster mailing list >>>> Linux-cluster@xxxxxxxxxx >>>> https://www.redhat.com/mailman/listinfo/linux-cluster >>> >>> >> >> >> -- >> Digimer >> Papers and Projects: https://alteeve.ca/w/ >> What if the cure for cancer is trapped in the mind of a person without >> access to education? >> >> -- >> Linux-cluster mailing list >> Linux-cluster@xxxxxxxxxx >> https://www.redhat.com/mailman/listinfo/linux-cluster -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
