[Gluster-devel] The return of the all-null pending matrix

[Emmanuel Dreyfus]

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 at netbsd.org