On Aug 4, 2013, at 4:19 PM, Duncan <1i5t5.dun...@cox.net> wrote: > Kai Krakow posted on Sun, 04 Aug 2013 14:41:54 +0200 as excerpted: > >> It is a RAID-1 so why bother with the faulty drive? Just wipe it, put it >> back in, then run a btrfs balance... There should be no data loss >> because all data is stored twice (two-way mirroring). > > The caveat would be if it didn't start as btrfs raid1, and there's still > some data (or possibly metadata if it was the single drive at one point > or they're ssds, as btrfs defaults to metadata single in ssd mode) that > hasn't been duped elsewhere.
I agree. I think tossing the data on the problematic device is a bit of a hammer. It may be necessary, but I don't think enough information has been provided to conclusively determine all other options have been explored. What kernel versions have been used? What does dmesg record beginning at the time of a normal mount attempt with all four devices available? What does btrfsck (without repair) report? Are there any prior kernel messages related to the controller or libata messages related to the suspect drive? What's the smartctl -x output for the suspect drive? Has mounting with -o recovery been attempted, and if so what were the messages recorded? 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
