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

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_at_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_at_bwct.de                                  info_at_bwct.de