From owner-freebsd-current Sat Feb 10 13:08:49 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA11173 for current-outgoing; Sat, 10 Feb 1996 13:08:49 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA11159 for ; Sat, 10 Feb 1996 13:08:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rover.village.org (8.6.11/8.6.6) with SMTP id OAA01488; Sat, 10 Feb 1996 14:08:25 -0700 Message-Id: <199602102108.OAA01488@rover.village.org> To: Terry Lambert Subject: Re: How Cc: current@FreeBSD.ORG In-reply-to: Your message of Sat, 10 Feb 1996 13:02:21 MST Date: Sat, 10 Feb 1996 14:08:25 -0700 From: Warner Losh Sender: owner-current@FreeBSD.ORG Precedence: bulk : You mean a hardware failure, right? A single failed metadata write : as a result of a crash before the write completes is *always* : recoverable with fsck. Yes. However, more than a single failed write was happening... : A hardware failure will either transparently forward the failed : sector, or if bad sector forwarding is being handled in software, : the BAD144 layer will cause the soft bad block map to be updated : and, again, the failed write will be remapped. The drive was lying to FreeBSD somehow. The sectors appeared to write correctly, but they were in fact unchanged or "random" for reasons unknown. As far as FreeBSD was concerned, it was dealing with a disk that was perfect. The disk drive, on the other hand, had other notions... It is entirely possible that FreeBSD 2.0R doesn't handle this sort of thing correctly. I've not delved enough to know for sure. I just know that I had a disk go bad and the corruption in the file system was rather large... Warner