From owner-freebsd-arch Mon Apr 2 9:18:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.wgate.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id 15F8337B71A for ; Mon, 2 Apr 2001 09:18:36 -0700 (PDT) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net ([10.32.2.26]) by mail.wgate.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H70XL0RA; Mon, 2 Apr 2001 12:18:34 -0400 Reply-To: Randell Jesup To: Kirk McKusick Cc: Randell Jesup , Bakul Shah , arch@FreeBSD.ORG Subject: Re: Background Fsck References: <200103302338.PAA11228@beastie.mckusick.com> From: Randell Jesup Date: 02 Apr 2001 12:21:02 -0400 In-Reply-To: Kirk McKusick's message of "Fri, 30 Mar 2001 15:38:42 -0800" Message-ID: User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kirk McKusick writes: >As far as I can tell, you have gone through and listed every >error exit in fsck... Most of these can only arise if the logic >is broken in some fundamental way. For example: Agreed, as I stated: :From the current source - I know that many of these are internal errors :that shouldn't happen, and are correct to exit out on. However, some :(like inoinfo(), ginode(), maybe getnextinode()) should NOT just cause :a blanket exit. >Similarly, inode numbers >that are out of bounds should have been discovered at a >higher level and dealt with (e.g., an out of bounds directory >entry should have been found and zapped). That is definitely not the case however; I found that out the hard way when a coworkers disk got scribbled on. I literally had to modify the source to FSCK to ignore those in order to recover the files that hadn't been trashed. > I do not disagree >that there may be some possibilities that slip through, but >going through and wholesale getting rid of error exits is >not the right approach. In general `fsck -p' will not fix >everything, but `fsck -y' should always succeed (though >success may be an empty filesystem). "fsck -y" does not always succeed (though I agree it should). The points I listed do not ask a question and exit regardless. You're correct that quite a few cannot happen unless there's a bug in fsck somewhere, but some (especially inoinfo() and ginode()) can and do happen in the case of true corruption. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message