Re: panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50

From: Bernd Walter <>
Date: Wed, 17 Sep 2003 22:27:55 +0200
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 <>, 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                              
Received on Wed Sep 17 2003 - 11:28:06 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:22 UTC