Date: Tue, 27 Nov 2007 22:22:40 +0100 From: Kris Kennaway <kris@FreeBSD.org> To: Doug Poland <doug@polands.org> Cc: questions@freebsd.org Subject: Re: Major filesystem problems after crash on 7.0-BETA3 Message-ID: <474C8AA0.7090701@FreeBSD.org> In-Reply-To: <21304.208.49.58.254.1196173362.squirrel@email.polands.org> References: <62327.208.49.58.254.1196108813.squirrel@email.polands.org> <19181.208.49.58.254.1196111022.squirrel@email.polands.org> <21304.208.49.58.254.1196173362.squirrel@email.polands.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?474C8AA0.7090701>