Major filesystem problems after crash on 7.0-BETA3

[Doug Poland]

On Mon, November 26, 2007 14:26, Doug Poland wrote:
> Hello,
>
> This morning my 7.0-BETA3 i386 system (Compaq nx7400) reset shortly
> after starting X11.  I didn't think much of it and went to get a cup
> of coffee while the background fsck took care of the file systems.
>
> Unforunately, something's still broke.  At first, when I tried to
> access the /var or /tmp filesystems, I received panics similar to:
>
> mode = 0100644, inum = 31127, fs = /tmp
> panic: ffs_valloc: dup alloc
> cpuid = 0
> Uptime: 9s
> Physical memory: 3435 MB
> Dumping 101 MB:Aborting dump due to I/O error.
> status == 0x4, scsi status == 0x0
>
> ** DUMP FAILED (ERROR 5) **
> Automatic reboot in 15 seconds - press a key on the console to abort
>
>
> After doing some googling, it looked like my filesystems weren't
> really clean after several manual runs of fsck.  So I disabled
> softupdates on /var and /tmp and ran fsck on those file systems again.
> After mounting them rw, I attempted to hit the filesystem again, this
> time getting a panic:
>
> panic: ffs_clusteralloc: map mismatch
> cpuid = 1
> Uptime: 6m40s
> Physical memory: 3435 MB
> Dumping 149 MB:Aborting dump due to I/O error.
> status == 0x4, scsi status == 0x0
>
> ** DUMP FAILED (ERROR 5) **
> Automatic reboot in 15 seconds - press a key on the console to abort
>
> Is there a way to identify and fix these errors?  I'm thinking a newfs
> of both /var and /tmp is in order.  I don't really care about /tmp,
> and I've backed up /var using dump(8).  My concern is if I restore
> /var on top of a newfs'd filesystem, I'll restore my broken files and
> have the same problem again.
>
Just a follow-up...  Everytime I run a  manual fsck on the problem
filesystems, it returns:

<snip>
BLK(S) MISSING IN BITMAPS
SALVAGE?
<snip>
***** FILE SYSTEM WAS MODIFIED *****


So it would appear that fsck is unable to repair damage, is that correct?

-- 
Regards,
Doug