Date: Tue, 5 Sep 1995 18:42:12 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: mpp@mpp.minn.net (Mike Pritchard) Cc: peter@taronga.com, hackers@FreeBSD.ORG Subject: Re: Bad superblock? Message-ID: <199509060142.SAA25004@phaeton.artisoft.com> In-Reply-To: <199509060049.TAA06186@mpp.minn.net> from "Mike Pritchard" at Sep 5, 95 07:49:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. Yes. The "clean bit" is dynamic information. The problem is that fsck specifically excepts fields it things aren't static when comparing superblocks. For a 1.x fsck, this include the (formerly unallocated) clean bit field. Sorry if this wasn't clear. > Can someone point me to a chunk of code in the kernel that actually does > write to any of the backup superblocks? Nothing does; the assumption that "the compare is good and the write is bad" is Peter's. In fact, the write never occurs because it is not supposed to ever occur. It is the compare that is "bad". But since 1.x doesn't support a clean flag anyway, then the result is the fsck cleaning the disk. Exactly as it did in 1.x, only for the wrong reason. Peter wants the fsck to honor the clean flag, but doesn't want to update to a file system type that supports clean flags in the first place. > 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". Yeah. Like spew unknown new symlink information into a directory structure, etc. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509060142.SAA25004>