FYI - this reminds me of a discussion I had once regarding bug 4321293 (Unable to exit svc_cots_kdup() all cache marked DUP_INPROGRESS).
<http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4321293> 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
