Re: minor patch for 2.1.87 NFS client

Bill Hawes (whawes@star.net)
Thu, 26 Feb 1998 22:59:23 -0500


Hans-Christoph Rohland wrote:

> Here are some more Errors:
> I am running 2.1.87 with your patch and padding enable. Now I can use
> 2.1 the first time, but I get:
>
> Feb 23 09:08:13 kernel: NFS: server hp, readdir reply truncated
> Feb 23 09:08:13 kernel: NFS: nr=170, slots=3, len=7

This is normal -- you'll get one message to show that the problem has been
detected, then the workaround is enabled. Once HP fixes their servers these will
go away :-)

> Feb 23 12:51:57 kernel: autofs: lookup failure on existing dentry, status = -2, name = clearcase.expview.vobs.sl
> Feb 23 12:51:57 kernel: autofs: trying to recover, but prepare for Armageddon
> [...]

Not sure about this one ...

> Feb 26 12:08:21 kernel: nfs_lookup: myname/Mail failed, error=-116
> Feb 26 12:08:21 kernel: nfs_lookup: myname/Mail failed, error=-116

Error 116 is a stale filehandle. Possibly someone deleted the file on the server
while it was in use? If you can reproduce this just from the client side, please
let me know what's causing it.

> Feb 26 12:08:31 kernel: nfs: RPC call returned error 111
> Feb 26 12:08:31 kernel: RPC: task of released request still queued!
> Feb 26 12:08:31 kernel: RPC: (task is on xprt_pending)
> Feb 26 12:08:31 kernel: nfs_lookup: myname/Mail failed, error=-111
> Feb 26 12:08:41 kernel: nfs: RPC call returned error 111
> Feb 26 12:08:41 kernel: RPC: task of released request still queued!
> Feb 26 12:08:41 kernel: RPC: (task is on xprt_pending)

These messages are caused by a configuration problem -- the portmapper needs to
be started before any NFS activity. Some of the distributions (e.g. RedHat)
start portmap too late ...

Regards,
Bill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu