From: Olaf Kirch <okir@suse.de>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Ian Kent <raven@themaw.net>, Charles Lever <cel@citi.umich.edu>,
nfs@lists.sourceforge.net
Subject: Re: [PATCH] Fix xprt_bindresvport range
Date: Mon, 28 Feb 2005 12:33:14 +0100 [thread overview]
Message-ID: <20050228113314.GG4822@suse.de> (raw)
In-Reply-To: <1109352644.15877.10.camel@lade.trondhjem.org>
On Fri, Feb 25, 2005 at 09:30:44AM -0800, Trond Myklebust wrote:
> As far as I know, all vendors use more or less the same scheme for the
> duplicate replay cache.
> ...and yes, the cache is important for TCP connections, since in the
> case of a network partition, the client may still have to resend RPC
> calls.
I understand the theoretical reasons, but I wonder about the practical
value. Any problem that causes retransmits over TCP is non-transient,
otherwise TCP retransmit would simply fix it for us (question - there
doesn't seem to be any code in sunrpc that breaks the connection after
a timeout, major or minor: I think we want that)
To make matters worse, the Linux client is fairly conservative on TCP
reconnects. TCP connects will time out after 60 seconds, and if the first
reconnect fails, we'll delay future reconnects by another 15 seconds.
In general I believe this is A Good Thing, but this timing pattern will
make sure there's not a shred of valid data left in your retransmit
cache by the time the connection comes back...
Finally, those 120 seconds are the upper limit on the life time of a
cached reply - those 1024 entries in the cache are far from sufficient if
you plan to deal with a few hundred workstations. If a client's
connection is dropped while he's in the middle of a sillyrename, the
server side cache will have been clobbered by the time he comes back.
And this is not theoretical; I've seen this happen in our R&D network.
The client/nfsd thread ratio was too high, so that nfsd started to drop
connections frequently. That caused interesting failures with silly
renames that were real fun to debug :)
> We are in the process of fixing the whole duplicate replay cache thingy
> in NFSv4.1, but until then, the current broken schemes that rely on RPC
> XID+program number+ipaddress+port number are liable to remain in use.
The most common case (AUTH_SYS) could be fixed by using the aup_machname
field from the credentials (NO, put down that clue stick, don't hit me,
I know it's wrong, ouch...!)
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
okir@suse.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2005-02-28 11:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-23 16:28 [PATCH] Fix xprt_bindresvport range Olaf Kirch
2005-02-23 16:35 ` Trond Myklebust
2005-02-24 2:59 ` Ian Kent
2005-02-24 4:23 ` Trond Myklebust
2005-02-24 10:14 ` Olaf Kirch
2005-02-24 18:12 ` Trond Myklebust
2005-02-25 9:28 ` Olaf Kirch
2005-02-25 17:30 ` Trond Myklebust
2005-02-28 11:33 ` Olaf Kirch [this message]
2005-02-25 0:54 ` Ian Kent
-- strict thread matches above, loose matches on Subject: below --
2005-02-23 17:05 Lever, Charles
2005-02-28 16:41 Lever, Charles
2005-02-28 16:57 ` Olaf Kirch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050228113314.GG4822@suse.de \
--to=okir@suse.de \
--cc=cel@citi.umich.edu \
--cc=nfs@lists.sourceforge.net \
--cc=raven@themaw.net \
--cc=trond.myklebust@fys.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.