I am suspecting it to be new quota-version introduced in the volume info
file which may have resulted in a checksum mismatch resulting into
peer rejection. But we can confirm it from log files and respective info
file content.
On Saturday 23 July 2016, B.K.Raghuram <bkrram at gmail.com> wrote:
> Unfortunately, the setup is at a customer's place which is not remotely
> accessible. Will try and get it by early next week. But could it just be a
> mismatch of the /var/lib/glusterd files?
>
> On Fri, Jul 22, 2016 at 8:07 PM, Atin Mukherjee <amukherj at redhat.com
> <javascript:_e(%7B%7D,'cvml','amukherj at
redhat.com');>> wrote:
>
>> Glusterd logs from all the nodes please?
>>
>>
>> On Friday 22 July 2016, B.K.Raghuram <bkrram at gmail.com
>> <javascript:_e(%7B%7D,'cvml','bkrram at
gmail.com');>> wrote:
>>
>>> When we upgrade some nodes from 3.6.1 to 3.7.13, some of the nodes
give
>>> a peer status of "peer rejected" while some dont. Is
there a reason for
>>> this discrepency and will the steps mentioned in
>>>
http://gluster-documentations.readthedocs.io/en/latest/Administrator%20Guide/Resolving%20Peer%20Rejected/
>>> work for this as well?
>>>
>>> Just out of curiosity, why the line "Try the whole procedure a
couple
>>> more times if it doesn't work right away." in the link
above?
>>>
>>
>>
>> --
>> Atin
>> Sent from iPhone
>>
>
>
--
Atin
Sent from iPhone
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20160723/f66f7010/attachment.html>