From owner-freebsd-hackers Wed Sep 26 10: 2:22 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id 3839B37B433 for ; Wed, 26 Sep 2001 10:02:19 -0700 (PDT) Received: from mindspring.com (dialup-209.247.137.184.Dial1.SanJose1.Level3.net [209.247.137.184]) by falcon.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f8QH2GA16385; Wed, 26 Sep 2001 10:02:16 -0700 (PDT) Message-ID: <3BB20A46.474E3C48@mindspring.com> Date: Wed, 26 Sep 2001 10:03:02 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian Reichert Cc: freebsd-hackers@freebsd.org Subject: Re: got bad cookie vp 0xe2e5ef80 bp 0xcf317328 References: <20010925093643.W49528@numachi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Brian Reichert wrote: > /* > * Yuck! The directory has been modified on the > * server. The only way to get the block is by > * reading from the beginning to get all the > * offset cookies. > * > * Leave the last bp intact unless there is an error. > * Loop back up to the while if the error is another > * NFSERR_BAD_COOKIE (double yuch!). > */ This is technically incorrect. Unless the directory has been truncated back, the way to do this is to do a mod on the block size for the offset given, and assume a compression of the directory block out from under you. So you do the mod, and then that gives you the directory block (compression does not occur across blocks), and then chain forward in the block until you have an index that exceeds the cookie index, and then go back one. The best way to do that is to remember the index one previous. In the case of a truncation, you're done. The ultimate "bad" result from this will be a duplicate entry from the iteration of the directory. Dealing with a duplicate entry is the job of the NFS client. Note that a directory iteration is just a "snapshot", much like "ps", and is not guaranteed to remain accurate, just as taking a polaroid picture of a crowd will not necessarily remain an accurate indicator of who is there, since it could change in the time between when the picture is taken and it develops. The best way would be to avoid cookies entirely, but FreeBSD is not structured for this (cookies were introduced in the 4.4-Lite release by NetBSD, and adopted by everyone else, including the 4.4-Lite2 release; NetBSD and OpenBSD have a different cookie parameter order than FreeBSD, as well). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message