Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Sep 2005 10:33:01 -0700 (PDT)
From:      Don Lewis <truckman@FreeBSD.org>
To:        kris@obsecurity.org
Cc:        freebsd-current@FreeBSD.org, obrien@FreeBSD.org
Subject:   Re: [PANIC] ufs_dirbad: bad dir
Message-ID:  <200509271733.j8RHX1MN099236@gw.catspoiler.org>
In-Reply-To: <20050927135350.GA94880@xor.obsecurity.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 27 Sep, Kris Kennaway wrote:
> On Tue, Sep 27, 2005 at 02:20:57AM -0700, Don Lewis wrote:
>> On 26 Sep, Kris Kennaway wrote:
>> > On Mon, Sep 26, 2005 at 09:08:08AM -0700, David O'Brien wrote:
>> >> On Mon, Sep 26, 2005 at 08:29:52AM -0700, David O'Brien wrote:
>> >> > Anyone own this one?
>> >> > The running kernel was:
>> >> >     FreeBSD 7.0-CURRENT #528: Sun Sep 25 21:07:22 PDT 2005
>> >> ... 
>> >> > panic messages:
>> >> > panic: ufs_dirbad: bad dir
>> >> 
>> >> Just got another one - uptime was about 10 minutes.  Is one of the recent
>> >> changes to SU & FFS making this situation easier to trigger?
>> > 
>> > As I've mentioned the last few times you reported this, it's a
>> > long-standing bug that has existed since the FreeBSD 4.x days or
>> > before.  Try to fsck -f your filesystems to make sure there is no
>> > lingering damage.
>> 
>> I think there is a soft updates bug that can leave directories in an
>> inconsistent state after a crash.  If you are experiencing this problem,
>> I would recommend making sure that all of your file systems are clean by
>> running fsck -f, and then disabling background_fsck.  Be on the lookout
>> for any unexpected soft updates inconsistencies after system crashes
>> (other than those caused by power failures if disk write caching is
>> enabled). If the ufs_dirbad panics still happen when starting from known
>> clean file systems, then the problem is something that I'm unaware of.
>> The message printed before the panic string would also be helpful.
> 
> I do not use bg fsck anywhere because of too many lingering problems
> after unclean shutdowns.  Moreover, on many of the machines I see this
> on, they newfs all their local filesystems at boot time (they
> netboot).  So one cause of this is either runtime corruption, or they
> have unreliable disks that are losing transactions.
> 
>> ufs_dirbad() should probably be re-written to combine the printf()
>> string with the panic() string.
> 
> In my case it's usually
> 
> ./ufs/ufs_lookup.c:                     ufs_dirbad(dp, dp->i_offset, "mangled entry");

This is something I've never encountered.  What does *ep look like?  Is
bp_bdata all zeros?  What are the file system block and fragment sizes?

If the problem is caused by hardware, I would expect you to also see
file data corruption.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200509271733.j8RHX1MN099236>