Major filesystem problems after crash on 7.0-BETA3

[Kris Kennaway]

Doug Poland wrote:
> On Mon, November 26, 2007 15:03, Doug Poland wrote:
>> 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?
>>
> Well, having stumped all the experts, I decided to reinstall from
> 7.0-BETA3 CD-ROM.  After a few minutes of writing to the disk after
> newfs, I got more panic: ffs_clusteralloc: map mismatch errors.  Since
> the device I'm writing to is a 3-day old Maxtor OneTouch III external
> HD, I've decided it must be a hardware failure and am returing the
> drive.
> 
> 

Yes, for whatever reason FreeBSD is unable to reliably perform I/O to 
the drive (hence the errors dumping).

Kris