Date: Tue, 5 Sep 1995 20:50:37 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: fenner@parc.xerox.com (Bill Fenner) Cc: terry@lambert.org, hackers@FreeBSD.ORG Subject: Re: Bad superblock? Message-ID: <199509060350.UAA29135@phaeton.artisoft.com> In-Reply-To: <95Sep5.192610pdt.177475@crevenia.parc.xerox.com> from "Bill Fenner" at Sep 5, 95 07:26:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> In message <199509060142.SAA25004@phaeton.artisoft.com> you write: > >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. > > I thought Peter wanted the 1.x fsck to not fail horribly and require a manual > fsck run, not that he wanted it to support the clean flag... ------------------------------------------------------------------------- "Taking the 'u' from his varsity sweater, Letter Man changes the 'fsck' into a ..." -- the lost episodes, #63: 'Letter Man gets laid' ------------------------------------------------------------------------- Peter wants the 1.x fsck to think it is clean after it has been mounted by 2.x fs code. Presumably he has done a clean shutdown and the clean flag is set. If fsck were in fact religious about honoring it, there would "not be a problem" (quoted, because I agree with fsck: it's the wrong thing to do). The problem is that it is in fact not clean as far as the criteria that the 1.x fsck uses to determine "clean" -- which is all 'unused' superblock and backup superblock fields must be identical. How 1.x fsck thinks Peter's drive is corrupt: 1) It checks the clean flag. 2) The clean flag can seem as if it OK. 3) Not trusting it, the fsck reads the primary superblock. 4) It checks it for corruption by grabbing the secondary superblock(s) and copying the "dynamic" fields from one to the other. 5) Then it bcmp's them. 6) And they don't match. Ha! The fsck was *right* to not just trust the clean flag! If it just honored the clean flag like Peter wanted, it would be mounting right now... 7) And it goes on it's merry way, reporting a corrupted superblock and fsck'ing the bejesus out of the drive (that's what fsck's do when they are on their merry way). Once again, what Peter can do: 1) Peter can hack his 1.x fsck to ignore the "unclean" stuff in the superblock that shouldn't be there but is because someone flubbed the 2.x/1.x backward compatability for the superblock structure and a 2.x FS writes some of the "static, 0" areas that it should not be writing if in fact it were truly backward compatible. This is dangerous: his superblock may in fact *be* corrupt. He can't know and his hacked fsck will be unable to tell him because one of it's consistency checks has been subverted if he hacks it. As a matter of fact, *I* think the drive is corrupt: it was corrupted by an incompatible file system implementation. 2) Peter can live with the 1.x fsck thinking his file system is unclean (because it *is* unclean) and fsck'ing it on him. 3) Peter can update his FS and quit running 1.x (probably not an option for him, and an end to much of the remaining 1.x support that people are currently benefitting from). 4) Peter can fix the backward compatability problem in FFS and the fixed 2.x FFS won't write the "static, 0" areas. 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?199509060350.UAA29135>