Hello Peter,

Friday, June 16, 2006, 11:33:01 AM, you wrote:

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

PH> <http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4321293>

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

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

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

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

Like hanging in ZFS due to txg throttling problem? :)
ok, I'm not sure if it's really the cause.

Best regards,
 Robert                            mailto:rmilkowski at task.gda.pl

Reply via email to