From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 13:28:06 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1057616A4D7 for ; Wed, 17 Sep 2003 13:28:06 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69A8F43FBF for ; Wed, 17 Sep 2003 13:28:03 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h8HKRw9H006097 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 17 Sep 2003 22:28:00 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h8HKRuhF074917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Sep 2003 22:27:56 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h8HKRtrY003153; Wed, 17 Sep 2003 22:27:56 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h8HKRtbR003152; Wed, 17 Sep 2003 22:27:55 +0200 (CEST) Date: Wed, 17 Sep 2003 22:27:55 +0200 From: Bernd Walter To: ticso@cicely.de, Poul-Henning Kamp , current@freebsd.org, Kris Kennaway Message-ID: <20030917202754.GF26878@cicely12.cicely.de> References: <20030916102534.J2924@gamplex.bde.org> <24374.1063782444@critter.freebsd.dk> <20030917082738.GW26878@cicely12.cicely.de> <20030917195203.GA75714@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030917195203.GA75714@funkthat.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i Subject: Re: panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2003 20:28:06 -0000 On Wed, Sep 17, 2003 at 12:52:03PM -0700, John-Mark Gurney wrote: > Bernd Walter wrote this message on Wed, Sep 17, 2003 at 10:27 +0200: > > On Wed, Sep 17, 2003 at 09:07:24AM +0200, Poul-Henning Kamp wrote: > > > In message <20030916102534.J2924@gamplex.bde.org>, Bruce Evans writes: > > > > > > >This is either disk corruption or an ffs bug. ffs passes the garbage > > > >block number 0xffffe5441ae9720 to bread. GEOM then handles this austerely > > > >by panicing. Garbage block numbers, including negative ones, can possibly > > > >be created by applications seeking to preposterous offsets, so they should > > > >not be handled with panics. > > > > > > They most certainly should! If the range checking in any filesystem > > > is not able to catch these cases I insist that GEOM do so with a panic. > > > > What is wrong with returning an IO error? > > > > I always hated panics because of filesystem corruptions. > > An alternative would be to just bring that filesystem down. > > Its easy to panic a whole system with a bogus filesystem on a removeable > > media. > > If you're file system is so hosed that it does this, then panicing > is the only safe thing to do. You don't know what continued operation > will do to the filesytem, and you might end up losing more data. You don't do anything to a filesystem if you force umount it on detected inconsistencies, but your system is still up. In which way could the filesystem further harmed? I have a bunch of MO media and also get media which were written by others - currently the only way to be safe is to fsck every media bevor mounting to not panic the system by just reading a removeable media. I have no clue on about how hard it is to implement, but I can't see anything wrong from the idea itself. As I already wrote in another mail - panicing inside GEOM sounds OK, because the FS shouldn't try to access unavailable blocks. > It is not unresonable to put parameter restrictions on function calls. > It is not much different from enforcing that a pointer is not NULL when > being passed as an argument. It is different - if a pointer is NULL then we have a software problem. If the filesystem is broken then the software might be OK and the cause could even be outside your own system. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de