On 2013-02-13, at 15:16 , Konstantin Belousov <kostik...@gmail.com> wrote:
> 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. I had sent out the output of procstat -kk at the time … for next time, would you need procstat against all of the 'duplicate processes' that aren't' killable? for instance, in this case, there were three du commands running doing the same thing,none of which were killable … so procstat -kk for all three of those? _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
