From owner-freebsd-stable Fri May 19 12:41:59 2000 Delivered-To: freebsd-stable@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 2083637BF55; Fri, 19 May 2000 12:41:51 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA40371; Fri, 19 May 2000 12:41:49 -0700 (PDT) (envelope-from dillon) Date: Fri, 19 May 2000 12:41:49 -0700 (PDT) From: Matthew Dillon Message-Id: <200005191941.MAA40371@apollo.backplane.com> To: Jaye Mathisen , hackers@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: NFS problems on 4.0-stable. References: Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :At 7:50 PM -0700 5/18/00, Jaye Mathisen wrote: :>UDP v2 mounts, Netapp Filer. :> :>Getting a fair # of: :>got bad cookie vp 0xd24bf1c0 bp 0xc9090500 :>got bad cookie vp 0xd24bfda0 bp 0xc906ceb0 :> :... :>on the console, and it seems to lock the machine up for several :>minutes when it does. Then it comes back to life, and cranks :>for a while... Hmmm. There is nothing 'wrong' per say with getting a bad cookie during a directory search. When FreeBSD gets a cookie error while scanning a directory, it has to start the scan over again. If you have a very large directory with lots of clients banging on it, a cookie error can result in a long delay. I am guessing that the long blockages are due to getting cookie errors on a very large directory. Why are you using a V2 mount? V3 mounts ought to perform much better, though the cookie error problem you are seeing will probably still be there. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message