From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?utf-8?B?SsO2cm4=?= Engel <joern@lazybastard.org>
Subject: Re: LogFS take four
Date: Mon, 4 Jun 2007 11:05:07 +0200
Message-ID: <20070604090507.GC14823@lazybastard.org>
References: <20070603183845.GA8952@lazybastard.org> <200706040018.23001.arnd@arndb.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mtd@lists.infradead.org, akpm@osdl.org,
	Sam Ravnborg <sam@ravnborg.org>,
	John Stoffel <john@stoffel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Jamie Lokier <jamie@shareable.org>,
	Artem Bityutskiy <dedekind@infradead.org>,
	CaT <cat@zip.com.au>, Jan Engelhardt <jengelh@linux01.gwdg.de>,
	Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
	David Weinehall <tao@acc.umu.se>, Willy Tarreau <w@1wt.eu>,
	Kyle Moffett <mrmacman_g4@mac.com>,
	Dongjun Shin <djshin90@gmail.com>, Pavel Machek <pavel@ucw.cz>,
	Bill Davidsen <davidsen@tmr.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Albert Cahalan <acahalan@gmail.com>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	Roland Dreier <rdreier@cisco.com>,
	Ondrej Zajicek <santiago@crfreenet.org>,
	Ulisses Furquim <ulissesf@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from lazybastard.de ([212.112.238.170]:55190 "EHLO
	longford.lazybastard.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751929AbXFDJJp (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Mon, 4 Jun 2007 05:09:45 -0400
Content-Disposition: inline
In-Reply-To: <200706040018.23001.arnd@arndb.de>
Sender: linux-fsdevel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Mon, 4 June 2007 00:18:21 +0200, Arnd Bergmann wrote:
> On Sunday 03 June 2007, J=C3=B6rn Engel wrote:
>=20
> > Unchanged:
> > o error handling
> >=20
> ...
> > Won't happen (unless I get convinced to do otherwise):
> > o Change LOGFS_BUG() and LOGFS_BUG_ON() to inline functions
> >   These are macros for very much the same reasons BUG() and BUG_ON(=
) are.
>=20
> I wonder how many of your LOGFS_BUG{,_ON} still remain after the
> error handling is in place to deal with broken file system contents.
> Ideally, I'd say the current LOGFS_BUG() should be replaced with
> a function that prints about the kind of error it has hit (rate-limit=
ed),
> potentially calls logfs_crash_dump(), and remounts the medium read-on=
ly,
> but _not_ call BUG().

That sounds fairly useful, actually.  Do a WARN_ON(), call
logfs_crash_dump(), remount read-only and finished.  Rate-limiting migh=
t
be unnecessary as the read-only thing already limits the rate to 1.

I like the idea.

J=C3=B6rn

--=20
=46ools ignore complexity.  Pragmatists suffer it.
Some can avoid it.  Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept.  1982
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel=
" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html