From owner-freebsd-hackers Tue Sep 5 17:49:31 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.freebsd.org (8.6.11/8.6.6) id RAA13344 for hackers-outgoing; Tue, 5 Sep 1995 17:49:31 -0700 Received: from mpp.minn.net (mpp.Minn.Net [204.157.201.242]) by freefall.freebsd.org (8.6.11/8.6.6) with ESMTP id RAA13334 for ; Tue, 5 Sep 1995 17:49:26 -0700 Received: (from mpp@localhost) by mpp.minn.net (8.6.11/8.6.9) id TAA06186; Tue, 5 Sep 1995 19:49:40 -0500 From: Mike Pritchard Message-Id: <199509060049.TAA06186@mpp.minn.net> Subject: Re: Bad superblock? To: peter@taronga.com (Peter da Silva) Date: Tue, 5 Sep 1995 19:49:40 -0500 (CDT) Cc: hackers@freebsd.org In-Reply-To: <199509052338.SAA25384@bonkers.taronga.com> from "Peter da Silva" at Sep 5, 95 06:38:12 pm X-Mailer: ELM [version 2.4 PL24 ME7a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1866 Sender: hackers-owner@freebsd.org Precedence: bulk [cc: list trimmed back] Peter da Silva wrote: > > > 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-). > > You are completely missing the point. > > When I umount under 2.0.5 it updates the clean bit on the superblock but > not on the backup superblock. When I boot 1.1.5.1, it sees the superblocks > are different and forces a manual fsck. > > Nothing is bad. I'm just wondering why umount doesn't set the clean bit in > the backup superblock. It's not saving anything, since the system is routinely > writing to the backup superblock anyway. And it provides the *illusion* of a > bad file system when the file system is perfectly good. Despite what Terry said, I don't think that the backup superblock is ever written to by anything else except newfs and in some cases fsck. The idea being that the backup superblocks contain all of the static information that is required to recompute all of the dynamic information stored in the superblock, and if you never write to it, you can't wreck it. Can someone point me to a chunk of code in the kernel that actually does write to any of the backup superblocks? > (yes, I know, it's not designed to handle switching file systems between the > two, but that's what you do during an upgrade on production hardware... the > system should be designed to make upgrades as easy as possible when it doesn't > cost anything) Personally, I feel much better doing a full fsck after running different OS levels with the same file system (especially production file systems). At least you know that one of the two versions didn't do something to the file system that the other one didn't like despite it claiming to be "clean". -- Mike Pritchard mpp@mpp.minn.net "Go that way. Really fast. If something gets in your way, turn"