From owner-freebsd-fs@FreeBSD.ORG Mon Sep 10 22:16:29 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A760016A418 for ; Mon, 10 Sep 2007 22:16:29 +0000 (UTC) (envelope-from jo_t@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 0263A13C457 for ; Mon, 10 Sep 2007 22:16:28 +0000 (UTC) (envelope-from jo_t@gmx.net) Received: (qmail invoked by alias); 10 Sep 2007 22:16:27 -0000 Received: from wh58-703.st.Uni-Magdeburg.DE (EHLO [192.168.73.100]) [141.44.198.73] by mail.gmx.net (mp056) with SMTP; 11 Sep 2007 00:16:27 +0200 X-Authenticated: #2964489 X-Provags-ID: V01U2FsdGVkX1/oGDlals/o2Eeonplx5P8aRDgzNEIB3W/1B1X0jg oD/1vDEmz5NHU7 Message-ID: <46E5C286.8010102@gmx.net> Date: Tue, 11 Sep 2007 00:17:42 +0200 From: Johannes Totz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Peter Schuller References: <46E4225F.1020806@gmx.net> <46E42D14.5060605@FreeBSD.org> <20070909200933.GA98161@hyperion.scode.org> In-Reply-To: <20070909200933.GA98161@hyperion.scode.org> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-fs@freebsd.org, Kris Kennaway Subject: Re: UFS not handling errors correctly X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2007 22:16:29 -0000 Peter Schuller wrote: >> bg fsck cannot fix arbitrary filesystem corruption. Nor is it >> intended to. > > But is not the proposed problem that UFS caused the corruption to > begin with? That is want I wanted to report. This corruption should not have happened in the first place. Either some part in geom did not properly report the error back to the upper layer (e.g. the file system); or UFS ignored it silently (as there is nothing in the logs). In any case, the behavior is not correct. But I must also admit that I have no idea what the correct behavior would be like: the write error was most likely a metadata flush (or softupdate checkpoint, not sure of the terminology here) because the (file-)system was idle at that time. Cheers Johannes