From owner-freebsd-bugs@FreeBSD.ORG Wed Mar 12 02:47:23 2008 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BB66106566B for ; Wed, 12 Mar 2008 02:47:23 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id E67948FC18 for ; Wed, 12 Mar 2008 02:47:22 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 03BDD2845A for ; Wed, 12 Mar 2008 10:47:22 +0800 (CST) Received: from localhost (tarsier.geekcn.org [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id C209BEC5A85; Wed, 12 Mar 2008 10:47:21 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id Qah3IBgLf-NA; Wed, 12 Mar 2008 10:47:17 +0800 (CST) Received: from charlie.delphij.net (71.5.7.139.ptr.us.xo.net [71.5.7.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 96386EC5A84; Wed, 12 Mar 2008 10:47:14 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=HWgEiNtxsXhD5aJQ2fQVn4PvJUhSOZUTaXsm5bogLKxk3iyOWQj65iqqhCBa0BmCS Adqekkte+p8j8nXO/H8Qw== Message-ID: <47D7442D.2080600@delphij.net> Date: Tue, 11 Mar 2008 19:47:09 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.12 (X11/20080309) MIME-Version: 1.0 To: Dieter References: <200803120230.m2C2U32p094690@freefall.freebsd.org> In-Reply-To: <200803120230.m2C2U32p094690@freefall.freebsd.org> X-Enigmail-Version: 0.95.6 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-bugs@FreeBSD.org 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: d@delphij.net List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 02:47:23 -0000 Dieter wrote: > 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. Are you really sure? Without a signature (UFS1_MAGIC or UFS2_MAGIC) in the superblock, fsck_ffs would not allow you to use that block as an alternative superblock... > 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? Try this: Index: fsutil.c =================================================================== RCS file: /home/ncvs/src/sbin/fsck_ffs/fsutil.c,v retrieving revision 1.26 diff -u -p -r1.26 fsutil.c --- fsutil.c 31 Oct 2006 22:06:56 -0000 1.26 +++ fsutil.c 22 Feb 2008 00:50:43 -0000 @@ -301,7 +301,7 @@ ckfini(int markclean) if (havesb && cursnapshot == 0 && sblock.fs_magic == FS_UFS2_MAGIC && sblk.b_bno != sblock.fs_sblockloc / dev_bsize && !preen && reply("UPDATE STANDARD SUPERBLOCK")) { - sblk.b_bno = sblock.fs_sblockloc / dev_bsize; + sblk.b_bno = SBLOCK_UFS2 / dev_bsize; sbdirty(); flush(fswritefd, &sblk); } Cheers, -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve!