On 08/23/2013 09:01 AM, Emmanuel Dreyfus wrote:
On Tue, Aug 20, 2013 at 11:07:00AM -0700, Anand Avati wrote:
This is a tricky problem. I have thought about this quite a bit and
couldn't come up with a theory which can lead to this behavior. I am
suspecting this might be a 32/64bit compatibility issue. Can you try
placing all bricks on the same architecture and see if this can be
reproduced?
Indeed, replacing the 64 bit brick by a 32 bit brick (like the 3 other ones)
seems to make the problem disapear.
I still have one issue that I already observed earlier. It is probbaly
unrelated, but it may be worth noting: after a few hours of operation,
gluster volume status waits forever and never output anything. Logs just say
that:
[2013-08-23 03:19:14.801204] I [glusterd-handler.c:3256:__glusterd_handle_status_volume] 0-management: Received status volume req for volume gfs340
Interrupting gluster with ^C, next attempt will get a failure "Another
transaction is in progress. Please try again after sometime." Log output:
[2013-08-23 03:22:35.424490] I [glusterd-handler.c:3256:__glusterd_handle_status_volume] 0-management: Received status volume req for volume gfs340
[2013-08-23 03:22:35.424555] E [glusterd-utils.c:329:glusterd_lock] 0-management: Unable to get lock for uuid: ebd8a16c-56b8-473e-ab7c-7f16b460bf8c, lock held by: ebd8a16c-56b8-473e-ab7c-7f16b460bf8c
[2013-08-23 03:22:35.424587] E [glusterd-syncop.c:1023:gd_sync_task_begin] 0-management: Unable to acquire lock
Seems like a lock held is not being relinquished. Can you provide the
output of:
gluster system:: fsm log
and
the glusterd log file?
-Vijay
