[PANIC] ufs_dirbad: bad dir
truckman at FreeBSD.org
Tue Sep 27 10:33:11 PDT 2005
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.
More information about the freebsd-current