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 -- Emmanuel Dreyfus manu@xxxxxxxxxx
