Re: continuous ffs_blkfree_common panic

[Andrius V <vezhlys%gmail.com@localhost>]

Hi,

On Sat, May 4, 2024 at 9:30 PM Chuck Silvers <chuq%chuq.com@localhost> wrote:
>
> once a UFS fs that is used with logging becomes corrupted, it will often
> stay corrupted until you manually run a full fsck on it ("fsck -fy").
> the "fsck -p" that is run automatically only does log replay, and if
> the metadata changes in the log do not fix the problem then the problem
> will escape detection and remain unfixed even when the fs is mounted r/w.
>

I ran fsck -f, however it didn't resolve the crash itself, system was
still on the crash loop.
I believe it stopped crashing when I accidentally moved one of the
affected files instead of copying, but can't tell for sure.
Was hoping to preserve the image but screwed up this time.
Since it happened when I was trying to set user's password, it seems
few passwd related files got corrupted during the process.

>
> this can happen with our journal implementation because regular file data
> is not journaled and there is no other mechanism to make sure that
> uninitialized blocks are either initialized or removed from the file
> after a crash.  no one has had the time to deal with this yet.
>
> -Chuck

Thanks for explanation, this is useful information.