For anyone stumbling across this thread: For my example, all was cleaned up by using the btrfs scrub:
btrfs scrub start /mountpoint No data lost. Good luck, Martin On 25/03/15 09:38, Martin wrote: > > Is that btrfs system formatted with a previous kernel (pre- > skinny-metadata) and is now being used with a kernel that newly has > skinny-metadata enabled by default?... > > > I've stumbled across a bug/change/patch listed for a mixed pre/post > skinny-metadata whereby you get to see lots of csum errors in the logs... > > For one 16TB btrfs raid1 system that brought things down to read-only... > > > I'm now on kernel 3.18.9, and Btrfs v3.18.2. Presently copying the > latest data onto a backup before trying a scrub! :-) > > LOTs of: > > kernel: parent transid verify failed on 5992676900864 wanted 70743 found > 70709 > kernel: parent transid verify failed on 5992676900864 wanted 70743 found > 70709 > kernel: BTRFS info (device sdj): no csum found for inode 50675726 start > 16384 > kernel: BTRFS info (device sdj): csum failed ino 50675726 off 0 csum > 42383870 expected csum 0 > kernel: BTRFS info (device sdj): csum failed ino 50675726 off 4096 csum > 815939273 expected csum 0 > > and variations seen. > > (Or advice for that one welcomed! ;-) ) -- 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
