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
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
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 0xe
In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>Don't you think that people will report them if the filesystem is
>automatically unmounted?
We can't sensibly do that.
>Accepted that's not an option for the GEOM point and that panicing
>here can be good to fix range checking in the filesyst
On Wed, Sep 17, 2003 at 10:30:15AM +0200, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Bernd Walter writes:
> >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 f
In message <[EMAIL PROTECTED]>, Bernd Walter writes:
>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 0xe5441ae9720 to bread.
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 0xe5441ae9720 to bread. GEOM then handles this austerely
> >by panicing. Garbage
In message <[EMAIL PROTECTED]>, Bruce Evans writes:
>This is either disk corruption or an ffs bug. ffs passes the garbage
>block number 0xe5441ae9720 to bread. GEOM then handles this austerely
>by panicing. Garbage block numbers, including negative ones, can possibly
>be created by applicat
On Tue, Sep 16, 2003 at 10:42:38AM +1000, Bruce Evans wrote:
> This is either disk corruption or an ffs bug.
Thanks. The disk this occurred on is a flaky IBM drive which
periodically experiences other kinds of FS corruption, so I'm inclined
to blame it.
Kris
pgp0.pgp
Description: PGP signa
On Mon, 15 Sep 2003, Kris Kennaway wrote:
> bad block 8239054478774324592, ino 3229486
> bad block 7021770428354685254, ino 3229486
> panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
> Debugger("panic")
> Stopped at Debugger+0x54: xchgl %ebx,
On Mon, Sep 15, 2003 at 08:24:24PM +0200, Poul-Henning Kamp wrote:
>
> 8239054478774324592 = 0x72570065646F4D70 = "rW\0edoMp"
>
> 7021770428354685254 = 0x617257006C6C6946 = "arW\0lliF"
>
> That looks suspicious to me...
Suspicious as indicating a kernel bug, or suspicious as in this panic
is sp
-ascii
>Content-Disposition: inline
>
>bad block 8239054478774324592, ino 3229486
>bad block 7021770428354685254, ino 3229486
>panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
>Debugger("panic")
>Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.
bad block 8239054478774324592, ino 3229486
bad block 7021770428354685254, ino 3229486
panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
Debugger("panic")
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c043aa25,c04ac1c0,c0435bc2,cd1
13 matches
Mail list logo
