On Sun, Jul 02, 2017 at 03:50:31PM +0200, Henk Slager wrote: > >With this patch applied to v4.11, I ran: ># btrfs check -p --mode lowmem /dev/mapper/smr > >no 'referencer count mismatch' anymore, but likely due to other hidden >corruption, the check took more time than I had planned, so after 5 >days, I cancelled it. > >As a summary, both kernel and lowmem check mention the same issue as >it looks like; for the lowmem check it is this, (repeating): >[...] >parent transid verify failed on 6350669414400 wanted 24678 found 24184 >parent transid verify failed on 6350645837824 wanted 24678 found 23277 >Ignoring transid failure >leaf parent key incorrect 6350645837824 >ERROR: extent[6349151535104 16384] backref lost (owner: 2, level: 0) >ERROR: check leaf failed root 2 bytenr 6349151535104 level 0, force >continue check >parent transid verify failed on 6350645837824 wanted 24678 found 23277 >Ignoring transid failure >leaf parent key incorrect 6350645837824 >ERROR: extent[6349150486528 16384] backref lost (owner: 2, level: 0) >ERROR: check leaf failed root 2 bytenr 6349150486528 level 0, force >continue check This looks like the extent tree has some problems. I would appreciate it if you could run the following command to dump the extent tree for me? # btrfs-debug-tree -t 2 /dev/mapper/smr | grep -C 10 -e 6349151535104 -e 6349150486528 >My plan is now to image the whole 8TB fs to extra/new storage hardware >with dd and then see if I can get the copy fixed. But it might take a >year before I do so (it is not critical w.r.t. data-loss, it's cold >storage, multi-year btrfs features test). > > -- Thanks, Lu -- 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
