Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 30 Jul 2001 18:51:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 30 Jul 2001 18:51:37 -0400 Received: from ns.caldera.de ([212.34.180.1]:8367 "EHLO ns.caldera.de") by vger.kernel.org with ESMTP id ; Mon, 30 Jul 2001 18:51:24 -0400 Date: Tue, 31 Jul 2001 00:50:49 +0200 From: Christoph Hellwig To: Kip Macy Cc: Rik van Riel , Hans Reiser , Christoph Hellwig , linux-kernel@vger.kernel.org, Vitaly Fertman Subject: Re: ReiserFS / 2.4.6 / Data Corruption Message-ID: <20010731005048.A29237@caldera.de> Mail-Followup-To: Christoph Hellwig , Kip Macy , Rik van Riel , Hans Reiser , linux-kernel@vger.kernel.org, Vitaly Fertman In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from kmacy@netapp.com on Mon, Jul 30, 2001 at 03:41:16PM -0700 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Original-Recipient: rfc822;linux-kernel-outgoing On Mon, Jul 30, 2001 at 03:41:16PM -0700, Kip Macy wrote: > How does compiling in debug infrastructure protect the user's data? By > making the file system so slow that he won't use it? :-) The <> isn't debugging code in a strict sense. It mostly it consists of sequences in the form of: (sometimes there is also code that the documentation states as deadlock- avoidance, why it is not enabled without _CHECK defined is left as exercise to the reader) #ifdef CONFIG_REISERFS_CHECK if (condition_that_should_not_happen) reiserfs_panic (sb, "some_obscure_error_code"); #endif This way the system stops with a indication of the failing component instead of silently corrupting disk contents. As reiserfs maintains a log the recovery from that panic shouldn't take that long either. (On the other hand I've seen some reiserfs systems that destroyed their disk contents while trying to recover. That's a reason why I still can't recomend using reiserfs for anything but /tmp, test machines or proxy caches). Christoph -- Of course it doesn't work. We've performed a software upgrade. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/