Date: Tue, 5 Sep 1995 19:49:40 -0500 (CDT) From: Mike Pritchard <mpp@mpp.minn.net> To: peter@taronga.com (Peter da Silva) Cc: hackers@freebsd.org Subject: Re: Bad superblock? Message-ID: <199509060049.TAA06186@mpp.minn.net> In-Reply-To: <199509052338.SAA25384@bonkers.taronga.com> from "Peter da Silva" at Sep 5, 95 06:38:12 pm
next in thread | previous in thread | raw e-mail | index | archive | help
[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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509060049.TAA06186>