Date: Tue, 27 Sep 2005 13:39:21 -0400 From: Kris Kennaway <kris@obsecurity.org> To: Don Lewis <truckman@FreeBSD.org> Cc: freebsd-current@FreeBSD.org, obrien@FreeBSD.org, kris@obsecurity.org Subject: Re: [PANIC] ufs_dirbad: bad dir Message-ID: <20050927173921.GA63323@xor.obsecurity.org> In-Reply-To: <200509271733.j8RHX1MN099236@gw.catspoiler.org> References: <20050927135350.GA94880@xor.obsecurity.org> <200509271733.j8RHX1MN099236@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 27, 2005 at 10:33:01AM -0700, Don Lewis wrote: > 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 > >> >> ...=20 > >> >> > panic messages: > >> >> > panic: ufs_dirbad: bad dir > >> >>=20 > >> >> Just got another one - uptime was about 10 minutes. Is one of the = recent > >> >> changes to SU & FFS making this situation easier to trigger? > >> >=20 > >> > 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. > >>=20 > >> I think there is a soft updates bug that can leave directories in an > >> inconsistent state after a crash. If you are experiencing this proble= m, > >> 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 kno= wn > >> clean file systems, then the problem is something that I'm unaware of. > >> The message printed before the panic string would also be helpful. > >=20 > > 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. > >=20 > >> ufs_dirbad() should probably be re-written to combine the printf() > >> string with the panic() string. > >=20 > > In my case it's usually > >=20 > > ./ufs/ufs_lookup.c: ufs_dirbad(dp, dp->i_offset, "m= angled entry"); >=20 > 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? I'll have to wait until I see this again, but I'll try to remember when it does. > If the problem is caused by hardware, I would expect you to also see > file data corruption. It's been a long time since I've seen corrupted files even on the machines that do not newfs their filesystems at boot, which have also panicked with this. Kris --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDOYPJWry0BWjoQKURAul1AKD4JPIHt1Q00FmyGLV5bkwkSXir4QCbBnez A3frP4ZW/XLM46a3oP+c2XY= =Op3x -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050927173921.GA63323>