Re: [PANIC] ufs_dirbad: bad dir

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.