now, what I found out: (is probably reproducible with
version I use, I'd imagine fairly critical)
There was a peer which had been, now I realize, not fully
detached, namely: three peers constituted a working cluster,
on these peers that fourth peer did not exist, was detached,
but that detach peer (was it network? hmm) still saw itself
(and other three peers) as a member of the cluster.
I did on "detached":
$ gluster peer status
and it would show three other peers. How it happened exactly
I cannot explain.
Nonetheless, that fourth-detached peer caused all these
problems it seems. As soon as I stopped gluster there I was
able to request all the actions successfully from the
gluster that before failed.
This in my mind is, if true, a serious problem, it will
cause a user/admin a headache when troubleshooting(like it
caused me), especially if that admin forgot there was
another peer somewhere(like I did, it was a VM in openstack)
Would be great if devel investigate or confirm, hopefully
new versions are/will be resilient to such cases of "ghost"
peers.
many thanks.
L
On 24/07/17 14:26, Atin Mukherjee wrote:> Yes it could as depending on number of bricks there might
> be too many brick ops involved. This is the reason we
> introduced --timeout option in CLI which can be used to
> have a larger time out value. However this fix is
> available from release-3.9 onwards.
>
> On Mon, Jul 24, 2017 at 3:54 PM, lejeczek
> <peljasz at yahoo.co.uk <mailto:peljasz at yahoo.co.uk>> wrote:
>
> hi fellas
>
> would you know what could be the problem with: vol
> status detail times out always?
> After I did above I had to restart glusterd on the
> peer which had the command issued.
> I run 3.8.14. Everything seems to work a ok.
>
> many thanks
> L.
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> <mailto:Gluster-users at gluster.org>
> http://lists.gluster.org/mailman/listinfo/gluster-users
> <http://lists.gluster.org/mailman/listinfo/gluster-users>
>
>