From owner-freebsd-bugs@FreeBSD.ORG Fri Mar 3 04:40:09 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CB0C16A42B for ; Fri, 3 Mar 2006 04:40:09 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EC1743D46 for ; Fri, 3 Mar 2006 04:40:09 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k234e8gx008069 for ; Fri, 3 Mar 2006 04:40:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k234e8ho008063; Fri, 3 Mar 2006 04:40:08 GMT (envelope-from gnats) Date: Fri, 3 Mar 2006 04:40:08 GMT Message-Id: <200603030440.k234e8ho008063@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Yarema Cc: Subject: Re: kern/93942: panic: ufs_dirbad: bad dir X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Yarema List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2006 04:40:09 -0000 The following reply was made to PR kern/93942; it has been noted by GNATS. From: Yarema To: Robert Watson Cc: FreeBSD-gnats-submit@freebsd.org, FreeBSD-current@freebsd.org, David Rhodus , Dennis Koegel , Martin Machacek , Kris Kennaway , Dmitry Pryanishnikov , Pawel Jakub Dawidek Subject: Re: kern/93942: panic: ufs_dirbad: bad dir Date: Thu, 02 Mar 2006 23:39:45 -0500 --On March 3, 2006 3:51:45 AM +0000 Robert Watson wrote: > > On Thu, 2 Mar 2006, Yarema wrote: > >> options UFS_EXTATTR >> options UFS_EXTATTR_AUTOSTART > > If you disable just UFS_EXTATTR_AUTOSTART, does the panic go away? The > autostart routine relies on reading directory data (or at least, > performing lookups) during the mount process. While it shouldn't be > running on UFS2, it could be that it is, and if something has changed in > the mount process so that reading directories that early is no longer > functional, it could be that this causes an incorrect reporting of > on-disk corruption (i.e., it could be a data structure initialization > problem or the like). > > Robert N M Watson Damn, I just reformatted the corrupt partition so I can no longer try this. But as per Dmitry's suggestion before newfs wiped it all I did a: mount -r /home cat /home > /tmp/ar0s1e.ino2 umount /home mount -r /dev/twed0s1e /home cat /home > /tmp/twed0s1e.ino2 umount /home Where ar0s1e is the corrupt slice and the dir is 17408 bytes in size and there seems to be a huge chunk of mostly null data following the entry for lost+found. twed0s1e is where I backed up the /home fs and the dir in a more reasonable 1024 bytes in size. Both files can be found at along with an archive of my KERNCONF files containing a short README explaining how I manage my KERNCONFs. -- Yarema