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 <[EMAIL PROTECTED]>, 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 [EMAIL PROTECTED] [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
