> >>>>> " " == Christoph Lameter <christoph@lameter.com> writes:
>
> > On Wed, 28 Apr 1999, Trond Myklebust wrote:
> >> This is just a function for initializing the cached inode,
> >> before it is filled in __nfs_fhget. Are you talking about the
> >> latter?
>
> > Right. Sorry.
>
> The reason why we don't have a limit to the number of tries there is
> because it should normally not be necessary. We only loop when we
> detect an inode as being stale: in which case we unhash it so that
> 'iget' returns a fresh inode.
>
> In theory, you can loop forever if the server is returning a zero
> value for fattr->nlink, but that would be a definite bug in the
> server. If you see it looping within that routine for some other case,
> I'd be very interested in details about the inode in question.
>
>
> Please note that there is a bug in 'nfs_lookup_revalidate' that has
> been reported to give problems with named sockets and the like. The
> latter seem (on some Linux servers) to have volatile file
> handles. This has been reported to cause a loop with dentry
> revalidation, in which case you would see a lot of messages from
> __nfs_fhget about freeing dentries and the like. Typically, it has
> been seen on NFSroot-based systems which access /tmp/.X11/X0.
>
> A fix for this problem has already been included in the pre-2.2.7
> patches, and has been in the '2.2.6-ac' series all along. Have you
> seen the problem with any of these kernels?
>
>
> Cheers,
> Trond
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/