|
In the logs I see, glusterd_lock()
being used. This api is called only in older versions of gluster
or if you have a cluster version is less then 30600. So along with
the version of glusterfs used, could you also let us know what is
the cluster version. You can check it as "operating-version" in
/var/lib/glusterd/glusterd.info file.
Regards,
Avra
On 04/21/2015 02:34 PM, Avra Sengupta wrote:
Hi Kondo,
Can u also mention the version of gluster you are using.
+Adding gluster-users
Regards,
Avra
On 04/21/2015 02:27 PM, Avra Sengupta wrote:
Hi Kondo,
I went through the gluster13 logs you had sent. Seems like
something on that machine is holding the lock and is not
releasing it. There are ways in which the system might end up
in this scenario. I will try and explain the same with an
example.
Let's say I have gluster 11, gluster12, and gluster 13 in my
cluster. I initiate a command from gluster11. Now the first
thing that command does is, it holds a lock on all the nodes
in the cluster on behalf of gluster11. Once the command does
what's intended, it's last act before ending is to unlock all
the nodes in the cluster. Now, only the node that has issued
the lock, can issue the unlock.
In your case what has happened is some command after
successfully acquired the lock on gluster13. Now the node
which initiated the command, went down or glusterd on that
node went down before it could complete the command and it
never got to send the unlock to gluster13.
There's a workaround to it. You can restart glusterd on
gluster13 and it should work fine.
Regards,
Avra
On 04/20/2015 06:55 PM, kenji kondo wrote:
Hello Vijay,
Maybe this is very rare case. But is there any idea?
Thanks,
Kondo
|
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users
