FYI - this reminds me of a discussion I had once regarding bug 4321293 
(Unable to exit svc_cots_kdup() all cache marked DUP_INPROGRESS).


That bug is fixed but someone thought they were still hitting it, turned 
out they were just hitting the limit you are seeing.

The cache is dynamically sized up to the limit of cotsmaxdupreqs 
(connection orientated, eg TCP) and maxdupreqs (connectionless, eg UDP).

The current behaviour is the expected effect of the fix to bug 4321293 
in that previously it would 'soft hang', now it just logs the error and 
returns an error to the client.

If the NFS server is stuck processing incoming requests so that it never 
replies then the incoming requests will fill up the dup request cache. 
In other words, if there's some other problem that is preventing the NFS 
server from replying to requests then you will also see this behaviour. 
In that case the dup syslog messages are a side effect of the underlying 
problem, ie the NFS server not being able to process requests at all, or 
at least fast enough.

-- Peter

Reply via email to