From owner-freebsd-hackers Mon May 15 20:14:47 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id UAA26298 for hackers-outgoing; Mon, 15 May 1995 20:14:47 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id UAA26292 for ; Mon, 15 May 1995 20:14:46 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.8/8.6.6) id UAA19487 for hackers@freebsd.org; Mon, 15 May 1995 20:14:46 -0700 Received: from sun-lamp.cs.berkeley.edu (sun-lamp.CS.Berkeley.EDU [128.32.138.88]) by ref.tfs.com (8.6.8/8.6.6) with ESMTP id BAA08826 for ; Sat, 13 May 1995 01:42:27 -0700 Received: from pain.lcs.mit.edu (pain.lcs.mit.edu [128.52.46.239]) by sun-lamp.cs.berkeley.edu (8.6.10/8.6.10) with ESMTP id BAA24667; Sat, 13 May 1995 01:35:57 -0700 Received: (from daemon@localhost) by pain.lcs.mit.edu (8.6.9/8.6.9) id EAA24119; Sat, 13 May 1995 04:34:37 -0400 Received: from disperse.demon.co.uk by pain.lcs.mit.edu (8.6.9/8.6.9) with SMTP id EAA24108; Sat, 13 May 1995 04:31:40 -0400 Received: from post.demon.co.uk by disperse.demon.co.uk id aa16889; 13 May 95 8:43 GMT-60:00 Received: from alice.wonderland.org by post.demon.co.uk id aa03253; 13 May 95 8:43 GMT-60:00 Received: (peter@localhost) by alice.wonderland.org (8.6.9/8.6.5) id IAA06452; Sat, 13 May 1995 08:37:08 +0100 From: Peter Galbavy Message-Id: <199505130737.IAA06452@alice.wonderland.org> Subject: Re: FSCK TROUBLE WITH 4.2 UNIX FILESYSTEMS To: Brian Buhrow Date: Sat, 13 May 1995 08:37:07 +0100 (BST) Cc: netbsd-help@NetBSD.ORG, current-users@NetBSD.ORG In-Reply-To: <199505122357.QAA11305@baloo.ucsc.edu> from "Brian Buhrow" at May 12, 95 04:57:40 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1073 X-Loop: netbsd-help@NetBSD.ORG Sender: hackers-owner@FreeBSD.org Precedence: bulk > When fsck performs sanity checks against the super block of a file system, > it does a comparison of the primary super block against the backup copy > located in the final cylinder group of the file system. If the comparison > fails, fsck requests that the user use the -b flag to specify an alternate > copy of the super block in order to restore the primary super block. If > the primary super block is corrupt, then it will be accurately updated at > the end of the fsck -b. The fsck -b procedure, however, does not update > the last copy of the super block in the filesystem. Thus, even if the > primary super block is correct, the next "fsck" will fail with the same > error. This I have seen. I could not "fix" the filesystem, and gave up by backing it up (mounted "dirty") and the newfs'ing it, and restoring. Not fun. If you can fix this... Regards, -- Peter Galbavy work: peter@demon.net Wonderland rest: peter@wonderland.org play: http://www.wonderland.org/ "The 'net interprets censorship as damage and routes around it." - John Gilmore