Date: Tue, 5 Sep 1995 17:20:53 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: peter@taronga.com (Peter da Silva) Cc: terry@lambert.org, peter@taronga.com, hackers@FreeBSD.ORG Subject: Re: Bad superblock? Message-ID: <199509060020.RAA24680@phaeton.artisoft.com> 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
> > 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. Ah. This is a completely different point from the one you made. 8-). The problem is that fsck compares the whole superblock instead of just the areas that it cares about. You need to make it not care about the clean stamp. If you'll rememebr, the clean flag wasn't in 1.x, so a "1.x fsck" will (correctly) fsck each time the system is booted. Personally, I would recommend allowing it to do this unless you choose to upgrade the FS to the new layout or modify the fsck, making it an "enhanced 1.x FS" instead of a "1.x FS" or "2.x FS". Of course, I'd advocate staying with the mainline code: update the disk or live with the fsck. 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?199509060020.RAA24680>