Date: Tue, 27 Sep 2005 15:51:56 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Don Lewis <truckman@FreeBSD.org> Cc: freebsd-current@FreeBSD.org, obrien@FreeBSD.org, kris@obsecurity.org Subject: Re: [PANIC] ufs_dirbad: bad dir Message-ID: <20050927155001.I34322@fledge.watson.org> In-Reply-To: <200509270921.j8R9Kvjh098113@gw.catspoiler.org> References: <200509270921.j8R9Kvjh098113@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050927155001.I34322>