<div dir="ltr">How does one figure out which node is holding the lock? A restart of glusterd on all the nodes in the pool did not seem to resolve the problem.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Fri, May 16, 2014 at 5:39 PM, Vijay Bellur <span dir="ltr">&lt;<a href="mailto:vbellur@redhat.com" target="_blank">vbellur@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 05/16/2014 12:24 PM, B.K.Raghuram wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A hard accidental power down of our boxes now results in the message<br>
&quot;Another transaction could be in progress. Please try again after<br>
sometime.&quot; for most volume operations. I&#39;m presuming this is the result<br>
of some sort of cluster lock. How does one get around the problem? Where<br>
are such lock files stored?<br>
<br>
</blockquote>
<br></div></div>
The cluster lock is a lock that is in memory and is not persisted. A restart of glusterd on the node that holds a stale lock would be helpful to recover from this state.<br>
<br>
Regards,<br>
Vijay<br>
<br>
</blockquote></div><br></div>