Date: Mon, 24 Apr 2006 21:35:25 -0400 From: Kris Kennaway <kris@obsecurity.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: <20060425013525.GA22427@xor.obsecurity.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
--y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 24, 2006 at 05:45:08PM -0700, Sam Leffler wrote: > Kris Kennaway wrote: > >On Mon, Apr 24, 2006 at 05:29:08PM -0700, Sam Leffler wrote: > >>Mohan Srinivasan wrote: > >>>mohans 2006-04-25 00:21:57 UTC > >>> > >>> FreeBSD src repository > >>> > >>> Modified files: > >>> sys/nfsserver nfsrvcache.h=20 > >>> Log: > >>> Bump up the NFS server dupreq cache limit to 2K (from 64). With a sma= ll > >>> duplicate request cache, under heavy load a lot of non-idempotent=20 > >>> 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. >=20 > Why is it hard to do a real fix? Or is this a temporary bandaid? AFAIK (Mohan will know more) other implementations do the same thing as we do, up to making the cache size scaled to RAM instead of statically sized. I guess if you make sure you hold on to every packet for a suitably long period of time then you can be sure you don't accidentally let through very delayed duplicate/retransmitted packets, but this could have unbounded memory requirements on a busy server. The main point though was that 64 is ludicrously low and easily overflowed in practise, and this change has minimal impact, mitigates the problem in practise, and is suitable for merging to 6.1. Kris --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFETXzdWry0BWjoQKURAh2sAKDvYm1rQiIVrZQ6WYfwKc4CGhKoIgCfaU/p 5ppK1iuBxFw5xzeVDi2RuuQ= =mZZD -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060425013525.GA22427>