Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Feb 2006 20:39:53 -0800 (PST)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        obrien@freebsd.org, David Rhodus <drhodus@machdep.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: It still here... panic: ufs_dirbad: bad dir
Message-ID:  <200602180439.k1I4drNm010220@apollo.backplane.com>
References:  <20060102222723.GA1754@dragon.NUXI.org>

next in thread | previous in thread | raw e-mail | index | archive | help

:Just in case anyone thought the bug had been fixed...
:
:FreeBSD 7.0-CURRENT #531: Mon Jan  2 11:32:17 PST 2006 i386
:
:panic: ufs_dirbad: bad dir
:...

:-- David  (obrien@FreeBSD.org)
:Q: Because it reverses the logical flow of conversation.
:A: Why is top-posting (putting a reply at the top of the message) frowned upon?

    We are still seeing it in DragonFly, too.  Right now I have two reports,
    one from DR, one from Tomaz.  It doesn't happen very often but it
    definitely still happens.

    I have already turned off background bitmap writes and I disallow inode
    reuse before the previous user finishes flushing its buffers out.  All
    related softupdates fixes made in FreeBSD have been ported to DragonFly.

    David, have you tried turning off doreallocblks ?  i.e. set 
    vfs.ffs.doreallocblks=0.  Both Davids, please try that, do a full manual
    fsck, and report if the problem still occurs.  If it doesn't fix it then
    we will at least eliminate another possible source for the problem.

    I wish there were a way to reliably reproduce the failure.

    I'm running out of ideas.  Right now my best idea is that there is
    something broken in the code that writes out the modified 'rewound'
    blocks.  Perhaps an old version of a buffer, with old already-reused 
    block pointers, is being written out and then something happens to 
    prevent the latest version from being written out.  I don't know, I'm
    grasping at straws here.  If I could only reliably reproduce the bug
    I would write some code to record every I/O operation done on the
    raw device then track back to the write that created the corruption.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



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