[PANIC] ufs_dirbad: bad dir

Robert Watson rwatson at FreeBSD.org
Tue Sep 27 07:51:57 PDT 2005

On Tue, 27 Sep 2005, Don Lewis wrote:

>> 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.
> ufs_dirbad() should probably be re-written to combine the printf() 
> string with the panic() string.

In the last week, on several occasions I've run into a situation where, 
following a clean shutdown/reboot during a heavy build or tar operations, 
the file system has come back up with minor corruption such that some 
directory entries return EBADF, and fsck reports that the inodes were 
partially cleared.  I've not yet reported it on a mailing list as I've 
only seen it happen with a development kernel with extensive changes (our 
audit development tree), and could be a property of those changes.  There 
may or may not be a correlation to a case where the syncer gives up on 
certain vnodes during the shutdown as a result of a reference leak of some 
sort.  I'll keep an eye out for it happening on a stock kernel though.

Robert N M Watson

More information about the freebsd-current mailing list