Date: Tue, 25 Apr 2006 09:48:01 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Sam Leffler <sam@errno.com> Cc: cvs-src@FreeBSD.org, Mohan Srinivasan <mohans@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: cvs commit: src/sys/nfsserver nfsrvcache.h Message-ID: <20060425094535.C44099@fledge.watson.org> In-Reply-To: <444D7114.1020106@errno.com> References: <200604250021.k3P0LvUZ033748@repoman.freebsd.org> <444D6D54.1000007@errno.com> <20060425003615.GA21881@xor.obsecurity.org> <444D7114.1020106@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Apr 2006, Sam Leffler wrote: >>>> sys/nfsserver nfsrvcache.h Log: >>>> Bump up the NFS server dupreq cache limit to 2K (from 64). With a small >>>> duplicate request cache, under heavy load a lot of non-idempotent >>>> requests >>>> were getting served again, resulting in errors. >>> How does increasing the cache size fix this problem? >> >> Fundamentally it doesn't, this change just pushes it out of the regime >> where it's trivial to overflow. > > Why is it hard to do a real fix? Or is this a temporary bandaid? It's really a problem with NFS over unreliable transports. You can get a variety of re-ordering, drop, duplicate delivery, etc, effects, which the RPC code has to try and handle as the transport doesn't. RPC over UDP doesn't have an ACK for replies, it simply has request retransmit, so the server has no way to know when a reply has been received, so it has to hold onto it. The reason for the idempotent/non-idempotent concern is that for idempotent operations, it doesn't matter if you execute them twice (by definition). However, some requests aren't idempotent -- rename, for example, won't behave the same way twice, so if you want to not return ENOENT for a retransmit of the request, you have to keep around the reply for a bit. Unpretty, but it's not clear what else you can do. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060425094535.C44099>