On Mar 15, 2013, at 5:21 AM, Roman Mamedov <rm@xxxxxxxxxx> wrote: > On Fri, 15 Mar 2013 12:07:47 +0100 (CET) > Roy Sigurd Karlsbakk <roy@xxxxxxxxxxxxx> wrote: > >>> What happened was: >>> - a device (sdg1) was added as a write-mostly member to a degraded >>> two-member RAID1 (md3) and started recovering; >> >> May I be so frank as to guessing you found an old drive and added as write-mostly? sdg is the bad drive here… > > This is correct, but I should note that I did not add it as write-mostly just > because it's an older drive, but because it is my normal set-up for md3: > a RAID1 mirror of a fast SSD (sdf) and a write-mostly HDD (sdg in this case). Again, I find it odd that sdg while rebuilding is reading any sectors. The read errors are coming from sdg. That it's also write-mostly enhances the mystery why sdg is being read from. I would fail the HDD, and btrfs scrub the array which in effect should scrub only sdf. And it may also need an offline btrfsck. The source (sdf) is already suspect because of btrfs not finding checksums where it was expecting to find them, and then on top of this you're getting sdg producing bad sector errors on reads. You might also consider posting the configuration and full dmesg to the btrfs list. I'm curious what btrfs developers think of this configuration. Chris Murphy P.S. Roman, there is a misconfigured MTA on your end, I always get emails from my MTAs indicating delays accepting handoffs of email only to you (with Reply All), it's possible it's wholesale rejecting an entire domain (comcast.net). If you want raw message source, you'll have to email me from a totally different account that I can forward to.-- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
