On Mon, Sep 24, 2012 at 07:41:03AM -0700, Marc MERLIN wrote: > It's possible, I have crappy drives that were cheap that I'm using for tests > and copies.
Yeah, that makes a good use of crappy disks :) > Considering that I was doing a huge copy to a brtfs filesystem (source was > ext4) and that I was using crappy drives in a 5 drives configuration > with no redundancy since there is no raid5 yet, it's very possible. Well, in your case raid1 might not be enough to protect the data. > 0: b7 6d mov $0x6d,%bh > 2: db b6 6d db b6 6d (bad) 0x6db6db6d(%rsi) > 8: 49 bd 00 00 00 00 00 movabs $0xffff880000000000,%r13 > f: 88 ff ff > 12: 49 c1 e0 03 shl $0x3,%r8 > 16: eb 43 jmp 0x5b > 18: 48 8b 8b 50 01 00 00 mov 0x150(%rbx),%rcx > 1f: 4c 89 d0 mov %r10,%rax > 22: 48 89 d7 mov %rdx,%rdi > 25: 4c 29 f8 sub %r15,%rax > 28: 4c 39 e0 cmp %r12,%rax > 2b:* 4a 8b 0c 01 mov (%rcx,%r8,1),%rcx <-- trapping > instruction ffff8800405ba2c8 + 007ffffffd4ebdc8 = 1007f88003daa6090 and overflows 64bit I'm afraid this does not tell much of the story. The last function that is not a struct helper was leaf_space_used(), via push_leaf_right, split_leaf() from btrfs_search_slot -- all sanity chcecks I see are past any of those calls, so it's probably corrupted on-disk. The call stack is unfortunatelly deep and going backwards in assembly to track where R11 could get set is tedious. Did you see any other messages in the log? If you could recreate the filesystem and workload, doing a fsck occasionally may narrow down the surface for analysis. Otherwise I'm out of ideas now. david -- 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
