From owner-freebsd-stable@FreeBSD.ORG Tue Mar 14 08:55:21 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65B9516A42F for ; Tue, 14 Mar 2006 08:55:21 +0000 (UTC) (envelope-from gemini@geminix.org) Received: from geminix.org (geminix.org [213.73.82.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3891D43D5E for ; Tue, 14 Mar 2006 08:55:18 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <441684F3.8030401@geminix.org> Date: Tue, 14 Mar 2006 09:55:15 +0100 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060129 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <4415E8BB.1080602@centtech.com> In-Reply-To: <4415E8BB.1080602@centtech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FJ5JE-0002KK-3U; Tue, 14 Mar 2006 09:55:16 +0100 Cc: freebsd-stable@freebsd.org Subject: Re: panic: ffs_valloc: dup alloc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 08:55:21 -0000 Eric Anderson wrote: > I get the above panic after nfs clients attach to this nfs server and > being read/write ops on it after an unclean shutdown. I've fsck'ed the > fs, and it marks it as clean, but I get this every time. It's an NFS > share of a GEOM stripe (about 2TB). > mode = 0100600, inum = 58456203, fs = /mnt > panic: ffs_valloc: dup alloc Do you happen to have disk mirroring on this server (RAID 1)? At work, on a workstation with RAID 1, we once had a case where after a power failure fsck would succeed, but subsequently, when mounting and using the partitions, the kernel still paniced because of a corrupt filesystem. Repeatedly. This caused some major head scratching on our part until we figured out what was happening. The mirrored disks had gone out of sync. For performance reasons, a RAID 1 controller reads data from one disk drive or the other, depending on which drive is less busy in that particular moment. So while fsck was able to find and fix some filesystem inconsistencies there were still some more left in disk sectors it didn't access. The RAID controller we used turned out to have a verification mode where it would scan the disks and re-synchronize them. Afterwards we did another fsck run, and this fixed the remaining filesystem inconsistencies. The kernel panics were gone. Now, with the information you've provided I can't tell whether these findings apply to your case, but perhaps this story helps at least others in a similar situation. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net