Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Aug 2003 04:35:32 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Lars Eggert <larse@ISI.EDU>
Cc:        current@freebsd.org
Subject:   Re: "got bad cookie" warnings/errors?
Message-ID:  <3F38D104.426ECD7D@mindspring.com>
References:  <200308100406.47211.coolvibe@hackerheaven.org> <20030810181824.GA14355@walton.maths.tcd.ie> <3F3693ED.40905@isi.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
Lars Eggert wrote:
> David Malone wrote:
> > I have a vague feeling they are related to a directory changing while it
> > is being read, and might mean that the NFS client sees an inconsistent
> > version of the directory. It's been a long time since I looked at it
> > though.
> 
> Sounds reasonable, but I'm not sure if is the case for me:
> 
> My home directory is NFS mounted from a Solaris box, and gets modified
> only from a single client (my desktop) at a time. I get these "cookie"
> messages whenever I log out of X, when a lot of things get read and
> written to that mount. Since all those reads and writes originate on my
> FreeBSD desktop, I would expect its NFS client to keep its cache
> consitent in that case.
> 
> But maybe not.

The problem is that the next iteration in the directory hits a bad
cookie error because a delete ocurred during an iteration.  If the
program that's doing the iteration to do the deletes (which is what
is likely happening) snapshotted the directory *then* did them, it
would all work fine.

Note that deleting from a shell doesn't have this problem, since
the globbing occurs in the shell, and the arguments are all
expanded before being passed to the "rm", so it doesn't have this
issue.

Basically, you have some badly behaved (for NFS) software.  You
can't really safely assume the server disk block size for the
back-off (not to mention duplicate suppression for a double rename
operation).

-- Terry



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F38D104.426ECD7D>