On Fri, 2008-10-03 at 19:10 +0200, Martin Bürger wrote: > On Friday 03 October 2008, Chris Mason wrote: > > On Fri, 2008-10-03 at 18:14 +0200, Martin Bürger wrote: > > > Hi, > > > I'm using the sources from [1] which I checked out today. When > > > testing the file system with compilebench [2] I traced oops [3] > > > (with 2 cores, SMP), [4] (single core), [5] (no smp) and [6] > > > (no-preemt). > > > > > > > > > [1] > > > git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unsta > > >ble.git [2] http://oss.oracle.com/~mason/compilebench/ > > > [3] http://rafb.net/p/1hUnky34.html > > > [4] http://rafb.net/p/kEGqY199.html > > > [5] http://rafb.net/p/pAHJrV88.html > > > [6] http://rafb.net/p/tkz92m77.html > > > > Hello, > > > > This is a long standing bug that so far we've only heard about on > > gentoo installs. Could you please give the attached patch a try > > against your sources? > > Here's a trace after having applied the patch [1]. > > [1] http://rafb.net/p/8zzEfe66.html > The interesting part of this is that every file created by compilebench is filled by the same pattern 4k of 'a'. Every corruption in Martin's trace looks the same: bad tree block start 7016996765293437281 74264576 7016996765293437281 is what we found on disk, the second number is what we expected to find. The number we found on disk is what you get when you have a u64 full of 'a'. This means that we're overwriting metadata blocks with data blocks. I'm looking harder. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
