(sdb&sdc are a raid0, btrfs receive destination, they don't come up in this dmesg at all)
sdd&sde are a raid1, btrfs send source All four devices are in USB enclosures on a new Intel NUC that's had ~32 hours burnin with memtest. Both file systems had received many scrubs before with zero errors all time, include most recently within the past few days. What's new about today's setup is the NUC, and the fact all four drives are directly connected, not to a USB hub. So right off the bat I'm going to suspect hardware problems are due to insufficient USB bus power. kernel messages: https://drive.google.com/open?id=0B_2Asp8DGjJ9Z0hhbVUwakF5Y2c Lines 6-28 I'm pretty sure what happens first is sdd is producing spurious data (bad tree block start). I can't tell if the 'read error correct' messages are fixing sde or sdd? In any case, since the last thing that happened before this was a passing scrub, none of these corrections written to disk are warranted and are suspect. Maybe what happens is the reads are bad but the writes back to the device (corrections) are OK. Next, line 29 to 48, looks like there is a USB bus reset, sde vanishes off the bus, and reappears as sdf, at which point thousands of write errors ensue. And then I became aware of all of this, did an abrupt shutdown (poweroff -f) at which point the journal ends. And then we go to part 1 for what I did next to try to recover. -- Chris Murphy -- 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
