Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Feb 2013 15:46:27 -0800
From:      "Marc G. Fournier" <scrappy@hub.org>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        Rick Macklem <rmacklem@uoguelph.ca>, freebsd-stable@freebsd.org, John Baldwin <jhb@freebsd.org>
Subject:   Re: 9-STABLE -> NFS -> NetAPP:
Message-ID:  <0AFE2DC0-A6C9-44D4-BEA4-C0223C25CBD8@hub.org>
In-Reply-To: <20130213231617.GZ2522@kib.kiev.ua>
References:  <20130213203042.GW2522@kib.kiev.ua> <431606432.2998831.1360795813954.JavaMail.root@erie.cs.uoguelph.ca> <20130213231617.GZ2522@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

On 2013-02-13, at 15:16 , Konstantin Belousov <kostikbel@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.
>=20
> 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.
>=20
> 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.
>=20
> 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 =85 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 =85 so =
procstat -kk for all three of those?






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0AFE2DC0-A6C9-44D4-BEA4-C0223C25CBD8>