From owner-freebsd-current@FreeBSD.ORG Wed Feb 20 21:01:20 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8014E16A401; Wed, 20 Feb 2008 21:01:20 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 3B55413C469; Wed, 20 Feb 2008 21:01:20 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.3] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m1KKXkiI054531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 12:33:50 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <47BC8E3E.2090706@FreeBSD.org> Date: Wed, 20 Feb 2008 12:31:58 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: d@delphij.net References: <47BBD864.3070905@delphij.net> <20080220105614.eydtkfap4gogk0cw@webmail.leidinger.net> <47BBF9CC.4030404@delphij.net> In-Reply-To: <47BBF9CC.4030404@delphij.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, Alexander Leidinger , FreeBSD Current Subject: Re: [PATCH FOR REVIEW] fsck_ffs: Recover from catastrophic damage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 21:01:20 -0000 Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Alexander Leidinger wrote: >> Quoting Xin LI (from Tue, 19 Feb 2008 23:36:04 >> -0800): >> >>> Change summary: >>> >>> fsutil.c: >>> - Really update standard superblock. fsck_ffs -b used to update the >>> backup superblock which does not recover file systems which have bad >>> master superblocks. >>> - Instead of coredump, zero out whole cg if its signature is bad. >>> >>> inode.c: >>> - Instead of coredump, zero out whole cg if its signature is bad. >> Does this modify (zero out) on-disk blocks? If yes, shouldn't this ask >> for confirmation? > > My assumption is that if a cylinder group's magic number is damaged, > then the whole stuff can not be trusted at all, but yes, I think this > should come with a prompt, will add tomorrow. Does it make sense to make this functionality only available if some special command-line flag has been specified? For example in the presence of silent data corruption (which as we all know now is real) it is possible that read would return incorrect data, while it's still perfectly OK on disk. Zeroing data would make an irreversible damage in such case. IMHO, fsck should bail by default in such case, since it can't tell for sure what the source of the error is. -Maxim