Major filesystem problems after crash on 7.0-BETA3 (SOLVED)

Doug Poland doug at polands.org
Wed Nov 28 11:57:42 PST 2007


On Tue, November 27, 2007 15:22, Kris Kennaway wrote:
> 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
>
New external harddrive solved the problem quite nicely.


-- 
Regards,
Doug



More information about the freebsd-questions mailing list