From owner-freebsd-current@FreeBSD.ORG Wed Jan 14 22:59:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19D3116A4CE for ; Wed, 14 Jan 2004 22:59:15 -0800 (PST) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 235B443D5C for ; Wed, 14 Jan 2004 22:59:13 -0800 (PST) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (localhost [127.0.0.1]) i0F6x3ZV072606; Thu, 15 Jan 2004 01:59:03 -0500 (EST) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)i0F6x2Q9072603; Thu, 15 Jan 2004 01:59:03 -0500 (EST) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Thu, 15 Jan 2004 01:59:02 -0500 (EST) From: Andre Guibert de Bruet To: "Lachlan O'Dea" In-Reply-To: Message-ID: <20040115015136.B47506@alpha.siliconlandmark.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean cc: freebsd-current@freebsd.org Subject: Re: Processes blocked on ufs or getblk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 06:59:15 -0000 On Thu, 15 Jan 2004, Lachlan O'Dea wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > I found some discussion about this in December, but I don't think > anyone has been able to get to the bottom of it yet. The symptom is > that processes become permanently blocked in a state of ufs or getblk. > I can reproduce it with find at will: > > % ps axl | grep ufs > 0 13225 13215 1 -4 0 1300 804 ufs D ?? 0:00.96 find > /var -xdev -type f ( -perm -u+x -or -perm -g+x -or -perm -o+ > 0 28778 28765 0 -4 0 1300 804 ufs D ?? 0:00.97 find > /var -xdev -type f ( -perm -u+x -or -perm -g+x -or -perm -o+ > 0 33017 32933 2 -4 0 1304 788 ufs D p2- 0:10.69 find > / -name samba > > It has also happened several times in single user mode to makewhatis > running at the end of installworld. > > System details: 5.2-RC FreeBSD 5.2-RC #1: Fri Jan 9 04:45:51 EST 2004. > Dell PowerEdge 2500. All filesystems are on a single raid 5 volume > using the aac driver. The box has two CPUs, but I'm currently running > with kern.smp.disabled=1. > > % mount > /dev/aacd0s1a on / (ufs, local) > devfs on /dev (devfs, local) > /dev/aacd0s1e on /usr (ufs, local, with quotas, soft-updates) > /dev/aacd0s1d on /var (ufs, local, soft-updates) > procfs on /proc (procfs, local) > linprocfs on /usr/compat/linux/proc (linprocfs, local) > > I also have ACLs enabled on /usr, if that's at all relevant. > > The kernel has DDB and DEBUG_LOCKS. Please let me know if there's > anything I can do to help debug this. > > I don't know if this is related, but another problem is that when > shutting down, it always gives up on a bunch of buffers. I think I've > seen over 100, but usually it's 4-10 buffers. I'm seeing the same thing on my desktop machine. It usually occurs while scanning large directories and/or dealing with large collections of files rather quickly. I came across this bug while using gqview to go through my image collection and a second time while re-checking out my ports tree from local cvs. The programs appear to grab an exclusive lock and anything that tries to read or write to the directory (or get a directory listing) gets stuck in ufs state. My kernel config is rather simple, GENERIC without a lot of cruft except amr, ata, scsi, usb and pcm. I'll try to get the output of a ddb ps and a show lockedvnods. The system in question is: FreeBSD bling.home 5.2-CURRENT FreeBSD 5.2-CURRENT #5: Tue Jan 6 22:32:09 EST 2004 root@bling.home:/usr/src/sys/i386/compile/BLING i386 I'm currently recompiling my kernel to see if this behavior is still around in newer CURRENT. Regards, > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/ >