Hello Duncan, > Of course if you'd been following the list as btrfs testers really > should still be doing at this point, you'd have seen all this covered > before. And of course, if you had done pre-deployment testing before > you stuck valuable data on that btrfs raid5, you'd have noted the > problems, even without reading about it on-list or on the wiki. But > of course hindsight is 20/20, as they say, and at least you DO have > backups, even if they'll take awhile to restore. =:^) That's already > vastly better than a lot of the reports we unfortunately get here. > =:^\
yeah, i saw it. Main reason for me "toying" with btrfs is my work. We rent Linux servers to customers. While they install and manage them by them self, there will be questions about btrfs to our support, sooner or later. So getting your hands on it early saves some headache later. It is just inconvient for me now, so no big deal. I first tried degraded, I also tried repair, no luck. What I do now is, getting as much data from the broken fs with btrfs recover and do a rsync after. It is just faster then downloading all the data from my own mirror in the datacenter. ;) After that I will even be so crazy and try it again. Next on my list is send/receive. Tetja -- 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
