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>