On Wed, 2009-04-29 at 14:21 -0400, Marc R. O'Connor wrote:
>
> Chris Mason wrote:
> > On Wed, 2009-04-29 at 12:04 -0400, Marc R. O'Connor wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> full file-item.c attached
> >>
> >> Chris Mason wrote:
> >>> On Tue, 2009-04-28 at 13:39 -0400, Marc R. O'Connor wrote:
> >>>> I have had two 'kernel bug' issues today both referencing file-item.c.
> >>>> The first oops happened when i was cp'ing from and external HD(ext3) to
> >>>> and ext3 partition. The second happened during boot up. I have attached
> >>>> them both.
> >>>>
> >>>> Im using btrfs that was merged into my kernel yesterday.
> >>>>
> >>>> plain text document attachment (btrfs_bug_1)
> >>>> Apr 28 10:55:10 cosmo2 ------------[ cut here ]------------
> >>>> Apr 28 10:55:10 cosmo2 kernel BUG at fs/btrfs/file-item.c:494!
> >>> Well, I think I see the bug. It looks like we want to do
> >>>
> >>> - if (key->offset < bytenr && csum_end <= end_byte) {
> >>> + if (key->offset <= bytenr && csum_end <= end_byte) {
> >>>
> >>> in truncate_one_csum. But I need to test that here for a bit and send
> >>> you a patch.
> >
> > Ok, line 494 is actually this one ;)
> >
> > key->offset = end_byte;
> > ret = btrfs_set_item_key_safe(trans, root, path, key);
> > BUG_ON(ret); <---- 494
> >
> > Which means we're finding things out of order in the btree leaf.
> >
> > Could you please run btrfsck on this filesystem?
> >
> I have done that on all btrfs partitions I have and btrfsck did not
> return anything odd.
>
In that case, the bad ordering is being introduced at run time. Could
you please run memtest86 on the box?
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
