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"); Kris
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:44 UTC