Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 29 Oct 2011 15:34:40 -0700
From:      Kirk McKusick <mckusick@mckusick.com>
To:        "deeptech71@gmail.com" <deeptech71@gmail.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: panic: ffs_blkfree_cg: freeing free block 
Message-ID:  <201110292234.p9TMYeSU047757@chez.mckusick.com>
In-Reply-To: <CAF6hryRK6KQsm6Rj90Ytv8xV1fZzPFAC46WV3nWihJgteVPwuQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Fri, 28 Oct 2011 11:16:59 +0200
> From: "deeptech71@gmail.com" <deeptech71@gmail.com>
> To: freebsd-current@freebsd.org
> Subject: panic: ffs_blkfree_cg: freeing free block
> 
> A panic occured while I was ``rm -rf''ing a large file&directory tree
> (that I just created with untar) on an old drive that I have not used
> for a long time. Unfortunately I'm not 100% sure that the filesystem
> was clean when I mounted it today. Could that result in such a panic?
> 
> I don't have the intermediate object files for the kernel; now I'm
> building the kernel again (from the appropriate, exact sources). That
> shouldn't harm debugging, should it? Meanwhile, I'll take any debug
> info requests, which I'll attempt to address shortly.

This panic happens when the free-block bitmap is corrupted. That can
happen due to:

1) An unclean filesystem being mounted (though you should get a warning
   when you attempt to do this).

2) Bit-rot on the disk that is not checked for before mounting. This is
   typically only an issue for a disk that has been offline for a long time.

3) Write errors to the disk.

There have been no changes to the code that manage the filesystem bitmaps
in decades (nearly three decades), so a software cause of this panic is
unlikely to have been recently introduced. Hence, I would not spend a lot
of time trying to get a backtrace, etc.

	Kirk McKusick



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201110292234.p9TMYeSU047757>