FYI: I ended up wipefs'ing the drive and adding it back in. I also has to abort the residual balance process to get the filesystem back to a state where I could add disk. I didn't realize this until after wiping the drive. Maybe if I'd known to look for that I could have recovered the drive before the wipe. Anyway, all seems fine now and I'm not mix and matching connection types.
More History: The filesystem came to a failed state during a balance just after adding the problem disk. This disk also had been installed inside the case on SATA instead of inside an external multi-drive enclosure. My thoughts at the time (now known to be semi-faulty) were it would be faster to push data into the disk that way. When the machine hardlocked this one drive was different enough from the other 3 I simply could not get btrfs to work with all four disks at once. On Sun, Aug 4, 2013 at 7:05 PM, Kai Krakow <hurikhan77+bt...@gmail.com> wrote: > Duncan <1i5t5.dun...@cox.net> schrieb: > >>> 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. > > Oh... That's actually a pitfall... :-\ > > Note to myself: Ensure balance has been run successfully and completely. > > -- > 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 -- Sandy McArthur "He who dares not offend cannot be honest." - Thomas Paine -- 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
