kern/119638: [ffs] fsck_ffs -b 32 doesn't repair primary superblock

[Dieter]

The following reply was made to PR kern/119638; it has been noted by GNATS.

From: Dieter <freebsd at sopwith.solgatos.com>
To: Yoshihiro Ota <ota at j.email.ne.jp>
Cc: bug-followup at 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?