[PANIC] ufs_dirbad: bad dir

Kris Kennaway kris at obsecurity.org
Tue Sep 27 10:39:23 PDT 2005


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
> >> >> ... 
> >> >> > 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?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20050927/98ca44d8/attachment.bin


More information about the freebsd-current mailing list