From owner-freebsd-current@FreeBSD.ORG Fri Mar 3 04:39:51 2006 Return-Path: X-Original-To: FreeBSD-current@freebsd.org 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 8B05916A420; Fri, 3 Mar 2006 04:39:51 +0000 (GMT) (envelope-from yds@CoolRat.org) Received: from dppl.com (sapas.dppl.net [216.182.10.231]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B75A43D45; Fri, 3 Mar 2006 04:39:51 +0000 (GMT) (envelope-from yds@CoolRat.org) Received: from [192.168.1.73] (c-69-242-5-144.hsd1.pa.comcast.net [69.242.5.144]) (AUTH: LOGIN yds) by dppl.com with esmtp; Thu, 02 Mar 2006 23:39:47 -0500 Date: Thu, 02 Mar 2006 23:39:45 -0500 From: Yarema To: Robert Watson Message-ID: <952927C621848163A912B270@ramen.coolrat.org> In-Reply-To: <20060303034932.V58513@fledge.watson.org> References: <20060228195343.GA85313@xor.obsecurity.org> <3BD79FAD83E2122EC1644386@ramen.coolrat.org> <20060301201937.GA29208@xor.obsecurity.org> <20060303034932.V58513@fledge.watson.org> X-Mailer: Mulberry/4.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: David Rhodus , Pawel Jakub Dawidek , Dennis Koegel , FreeBSD-current@freebsd.org, Martin Machacek , Kris Kennaway , Dmitry Pryanishnikov , FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/93942: panic: ufs_dirbad: bad dir X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 03 Mar 2006 04:39:51 -0000 --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