activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James A. Robinson" <jim.robin...@gmail.com>
Subject Re: NFS v4 locks "given up" w/o any logging?
Date Tue, 22 Mar 2016 21:48:20 GMT
To answer my own question, no (at least not NFS 4):

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-nfs.html


On Mon, Mar 21, 2016 at 3:46 PM James A. Robinson <jim.robinson@gmail.com>
wrote:

> I suppose I should pose the question to folks that use NFS, do you use TCP
> or UDP for your NFS stack?
>
>
> On Mon, Mar 21, 2016 at 3:29 PM James A. Robinson <jim.robinson@gmail.com>
> wrote:
>
>> Running a packet trace while the problem was occurring let me see that
>> the problem is that the NFS layer isn't even being involved for 3 minutes
>> due to the TCP layer retrying for 3 minute before notifying the caller of
>> the error.
>>
>> The client sends SYN packets, doesn't get an ACK, and finally times out
>> after 3 minutes.  The documentation for Linux (the client in this case)
>> indicates the following default:
>>
>> tcp_syn_retries (integer; default: 5; since Linux 2.2)
>>               The maximum number of times initial SYNs for an active TCP
>>               connection attempt will be retransmitted.  This value should
>>               not be higher than 255.  The default value is 5, which
>>               corresponds to approximately 180 seconds.
>>
>> I think this means that it's not possible to get faster failover w/o
>> modifying the default values for the TCP layer.  This particular error is
>> always going to take at least 3 minutes to surface.
>>
>> Jim
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message