From owner-freebsd-hackers Tue Sep 5 15:46:41 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.freebsd.org (8.6.11/8.6.6) id PAA09767 for hackers-outgoing; Tue, 5 Sep 1995 15:46:41 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.11/8.6.6) with ESMTP id PAA09761 for ; Tue, 5 Sep 1995 15:46:37 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA24452; Tue, 5 Sep 1995 15:41:33 -0700 From: Terry Lambert Message-Id: <199509052241.PAA24452@phaeton.artisoft.com> Subject: Re: Bad superblock? To: peter@taronga.com (Peter da Silva) Date: Tue, 5 Sep 1995 15:41:33 -0700 (MST) Cc: terry@lambert.org, peter@taronga.com, hackers@FreeBSD.ORG In-Reply-To: <199509052102.QAA22315@bonkers.taronga.com> from "Peter da Silva" at Sep 5, 95 04:02:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1197 Sender: hackers-owner@FreeBSD.ORG Precedence: bulk > > If the answer could be "controller failure" than the reason it doesn't > > update the backup superblocks should be obvious. > > Doesn't "sync" update the backup superblock anyway? yes, but not the clean bit. Consider a failure and a loss of the original superblock; to be consistent, the backup superblock must force a fsck. This all boils down to an issue of media perfection and the fact that a sector failure can take out critical data at all; or in the particular case that started this thread, the MSDOSFS can be of by two bytes and blow your superblock. Trying to optimize for the case of a particular know failure is a bogus exercise. Either fix the failure or live with the existing recovery; the existing recovery takes a lot more failure modes than the MSDOSFS crap into account, and losing them because a similar but not identical failure has occured (and is thus not recoverable) is a Bad Thing(tm). If this isn't your issue, then you don't have an issue; your superblock is good, use it instead of trying to play with a backup. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.