9-STABLE -> NFS -> NetAPP:

Konstantin Belousov kostikbel at gmail.com
Wed Feb 13 23:16:31 UTC 2013


On Wed, Feb 13, 2013 at 05:50:13PM -0500, Rick Macklem wrote:
> I got it resent from him. I've attached it to this post, just in case you
> are interested in taking a look at it.

I do not see the voffset wchains surprising. All of them seems to occur
in the multithreading process.  The usual reason for the voffset blocking
is the use of the same file (as in struct file *) to perform operations
from several threads in parallel.  One thread locked the file offset by
using read() or write(), and sleeping waiting for the vnode locked.
All other threads performing read or write on the same file, e.g. by
using the same file descriptor, are locked on the file offset before
even trying to lock the vnode.

What I see interesting in the output you mailed, is the pid 93636. Note
that several its threads are in the 'T' state. It means stopped, while
other threads obviously do file i/o due to vofflock state. I wonder if
some stopped thread owns nfs vnode lock. It could be some omission in the
handling of PBDRY/TDF_BDRY, or other bug.

It is absolutely impossible to say anything definitive without proper
diagnostic.  At least the procstat -kk is needed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20130214/7cc0cff0/attachment.sig>


More information about the freebsd-stable mailing list