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

From: John-Mark Gurney <>
Date: Wed, 17 Sep 2003 14:24:35 -0700
Bernd Walter wrote this message on Wed, Sep 17, 2003 at 22:27 +0200:
> > 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.

there is nothing wrong with the idea, but implementation is difficult.
As far as GEOM is considered, it just gets data read/write requests from
various backing objects, but has no idea what fs or even if it is an
fs that is trying to access the block.  It could be broken swap code,
or some person's custom kernel web server, etc.  GEOM just can't know
how to behave in these cases.

> 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.

If the filesystem is broken, then we still have a software bug for not
asserting that the properties of the fs is maintained.  If/when we ever
support user mounting fs's, we need to make sure that the fs doesn't do
wacky things and provide a way to escelate permissions or crash the box.

  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
Received on Wed Sep 17 2003 - 12:24:41 UTC

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