From owner-freebsd-stable@FreeBSD.ORG Wed Feb 13 23:46:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BAF21306; Wed, 13 Feb 2013 23:46:30 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 8138A846; Wed, 13 Feb 2013 23:46:30 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.189]) by hub.org (Postfix) with ESMTP id B3F7F1BB1AB4; Wed, 13 Feb 2013 19:46:29 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.189]) (amavisd-maia, port 10024) with ESMTP id 33829-03; Wed, 13 Feb 2013 23:46:29 +0000 (UTC) Received: from [10.5.250.150] (remote.ilcs.sd63.bc.ca [142.31.148.2]) by hub.org (Postfix) with ESMTPA id 9AED81BB1AB3; Wed, 13 Feb 2013 19:46:28 -0400 (AST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 9-STABLE -> NFS -> NetAPP: From: "Marc G. Fournier" In-Reply-To: <20130213231617.GZ2522@kib.kiev.ua> Date: Wed, 13 Feb 2013 15:46:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0AFE2DC0-A6C9-44D4-BEA4-C0223C25CBD8@hub.org> References: <20130213203042.GW2522@kib.kiev.ua> <431606432.2998831.1360795813954.JavaMail.root@erie.cs.uoguelph.ca> <20130213231617.GZ2522@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1499) Cc: Rick Macklem , freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:46:30 -0000 On 2013-02-13, at 15:16 , Konstantin Belousov = 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?