From owner-freebsd-bugs@FreeBSD.ORG Wed Mar 12 02:30:03 2008 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB61D1065672 for ; Wed, 12 Mar 2008 02:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A84318FC21 for ; Wed, 12 Mar 2008 02:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2C2U3NN094693 for ; Wed, 12 Mar 2008 02:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2C2U32p094690; Wed, 12 Mar 2008 02:30:03 GMT (envelope-from gnats) Date: Wed, 12 Mar 2008 02:30:03 GMT Message-Id: <200803120230.m2C2U32p094690@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Dieter Cc: Subject: Re: kern/119638: [ffs] fsck_ffs -b 32 doesn't repair primary superblock X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dieter List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 02:30:03 -0000 The following reply was made to PR kern/119638; it has been noted by GNATS. From: Dieter To: Yoshihiro Ota 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?