Date: Wed, 12 Mar 2008 02:30:03 GMT From: Dieter <freebsd@sopwith.solgatos.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/119638: [ffs] fsck_ffs -b 32 doesn't repair primary superblock Message-ID: <200803120230.m2C2U32p094690@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/119638; it has been noted by GNATS. From: Dieter <freebsd@sopwith.solgatos.com> To: Yoshihiro Ota <ota@j.email.ne.jp> Cc: bug-followup@FreeBSD.org Subject: Re: kern/119638: [ffs] fsck_ffs -b 32 doesn't repair primary superblock Date: Tue, 11 Mar 2008 14:31:49 +0100 > Was your filesystem on /dev/da0s1 "UFS version 1?" > > See "man fsck_ffs": > > -b Use the block specified immediately after the flag as the super > block for the file system. An alternate super block is usually > located at block 32 for UFS1, and block 160 for UFS2. > > If you had UFS2, which is the default since 5.1-RELEASE for almost 4 years, > you should have used 160, instead. AAAUUGHH!!! For decades, FFS always used 32 as the first backup superblock, and now some rocket scientist has broken it. Now we have some random block. :-( 160? I'm getting block 256 as the first alternate. Despite this, fsck was perfectly happy using whatever bits happened to be at block 32 and mangled the filesystem accordingly. Except it didn't repair the primary superblock for some reason. Fsck accepting block 32 when it isn't really the superblock is a whole other (more difficult) problem. If block 32 is a data block, there is nothing stopping it from looking like a superblock. Have to think about that one. This PR is about fsck not repairing the primary superblock. Why didn't fsck repair the primary superblock once it had mangled everything else into compliance?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200803120230.m2C2U32p094690>