Quoting Andrew Deason adea...@sinenomine.net:
If you want to look at this further, capturing network traffic to/from
an idle client that triggers this would help say why. ...
Or, if you turn the fileserver debugging up to at least 2 ... you
could see how often you see this message:
On Tue, 17 May 2011 14:29:08 +0200
Jaap Winius jwin...@umrk.nl wrote:
Somehow I'm not too interested in capturing lots of packets if you're
unsure that will do any good.
Well, I'm sure it will aid in understanding the 1.4 situation, but
whether it will actually help solve your problem I'm
Quoting Andrew Deason adea...@sinenomine.net:
http://git.openafs.org/?p=openafs.git;a=commitdiff_plain;h=fdc29c662e86f44ae80b304377111a10866276dd
That's against the 1.4 head, but it should apply fine to your source as
well. You still want a timeout of at least around 20 minutes with that,
but
On Mon, 16 May 2011 23:19:23 +0200
Jaap Winius jwin...@umrk.nl wrote:
After almost a day of operations with your patch in place and both UDP
timeout values set to 3600 seconds, there were just a few dropped
packets. Not having noticed that immediately (it was on the one server
I didn't
On Sat, 14 May 2011 00:38:44 +0200
Jaap Winius jwin...@umrk.nl wrote:
The source compiled just file with your patch. I have a question,
though. Once compiled, the Debian openafs source produces a bunch of
packages. But it's only patched the openafs-fileserver package that I
need to install,
Quoting Andrew Deason adea...@sinenomine.net:
Sorry for the delay. Apply this:
http://git.openafs.org/?p=openafs.git;a=commitdiff_plain;h=fdc29c662e86f44ae80b304377111a10866276dd
That's against the 1.4 head, but it should apply fine to your source as
well. You still want a timeout of at least
On Tue, 10 May 2011 01:23:15 +0200
Jaap Winius jwin...@umrk.nl wrote:
The patch for this is simple, though. Jaap, if you want to run with
smaller timeouts, we can get you a fileserver patch that should make
them workable. (I'm assuming this is a 1.4 fileserver?)
That would be welcome! My
On Fri, 6 May 2011 15:02:47 -0500
Andrew Deason adea...@sinenomine.net wrote:
After that, we won't ping the server anymore, but the fileserver still
has the client's associated host structure in memory, and only pings
the client every 15 minutes.
...but this is also only if the client still
On 5/9/2011 10:47 AM, Andrew Deason wrote:
On Fri, 6 May 2011 15:02:47 -0500
Andrew Deason adea...@sinenomine.net wrote:
After that, we won't ping the server anymore, but the fileserver still
has the client's associated host structure in memory, and only pings
the client every 15 minutes.
On Mon, 09 May 2011 11:03:42 -0400
Jeffrey Altman jalt...@secure-endpoints.com wrote:
The port number used is irrelevant. The question is whether the
firewall or NAT keeps the port open or not. There is no guarantee
that a client will use port 7001 either. That is simply the standard
port.
On 5/9/2011 11:25 AM, Andrew Deason wrote:
On Mon, 09 May 2011 11:03:42 -0400
Jeffrey Altman jalt...@secure-endpoints.com wrote:
The port number used is irrelevant. The question is whether the
firewall or NAT keeps the port open or not. There is no guarantee
that a client will use port
On Mon, 09 May 2011 11:42:24 -0400
Jeffrey Altman jalt...@secure-endpoints.com wrote:
Most NATs assign the requested port on a first come first serve basis.
Firewalls that only open ports in response to outgoing traffic will
also require this functionality.
That is true; nevermind what I
On Mon, May 9, 2011 at 12:15 PM, Andrew Deason adea...@sinenomine.net wrote:
On Mon, 09 May 2011 11:42:24 -0400
Jeffrey Altman jalt...@secure-endpoints.com wrote:
Most NATs assign the requested port on a first come first serve basis.
Firewalls that only open ports in response to outgoing
Quoting Andrew Deason adea...@sinenomine.net:
The patch for this is simple, though. Jaap, if you want to run with
smaller timeouts, we can get you a fileserver patch that should make
them workable. (I'm assuming this is a 1.4 fileserver?)
That would be welcome! My fileserver version is
On Fri, 06 May 2011 13:10:33 +0200
Jaap Winius jwin...@umrk.nl wrote:
Quoting Jeffrey Altman jalt...@secure-endpoints.com:
10 to 15 minutes is more than sufficient.
Since ip_conntrack_udp_timeout and ip_conntrack_udp_timeout_stream
were decreased from 28800 to 900 seconds, I've been
On Thu, 05 May 2011 16:40:25 +0200
Jaap Winius jwin...@umrk.nl wrote:
Nevertheless, 10-15 minutes is still 20-30x the default value. As an
alternative solution, could setting something like...
fs checkservers -interval 10
... on the clients be just as effective? Or, even if it is,
16 matches
Mail list logo
