On Sat, Feb 6, 2016 at 5:40 PM, Tom Arild Naess <tanaess@xxxxxxxxx> wrote: >>> This is not what I expect from a raid10! >> >> Technically what you don't expect from raid10 is any notification that >> the file may be corrupt at all. It'd be interesting to extract the >> file with restore, and then compare hashes to a known good copy. > > Well, I really don't expect this to be happening at all. If this is a bug in > btrfs, it could just as well have struck the same file on the server. Seems like a bug in that the results are definitely not expected. But there isn't enough information to isolate the source. I'm not aware of any sort of Btrfs bug like this. >This being a 16GB edited family film video file, I had the > original source deleted, so I could very well end up with some very annoying > chop in the video in a worst case scenario. > > Anyway, I just hope that if there is a bug in the code, this could help find > it. There isn't enough information to know what's even going on in this particular instance, let alone to deduce if there's a bug in the code. The entire dmesg would be more helpful than just one snippet, because invariably the problem occurred before the uncorrectable corruption messages appear. Whether or not the kernel messages report the instigator is another question, it may have happened this boot, or some other boot you no longer even have messages for. Chris Murphy -- 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
