On Jan 9, 2014, at 11:22 AM, Austin S Hemmelgarn <[email protected]> wrote:
> On 2014-01-09 13:08, Chris Murphy wrote: >> >> On Jan 9, 2014, at 5:41 AM, Duncan <[email protected]> wrote: >>> Having checksumming is good, and a second >>> copy in case one fails the checksum is nice, but what if they BOTH do? >>> I'd love to have the choice of (at least) three-way-mirroring, as for me >>> that seems the best practical hassle/cost vs. risk balance I could get, >>> but it's not yet possible. =:^( >> >> I'm on the fence on n-way. >> >> HDDs get bigger at a faster rate than their performance improves, so rebuild >> times keep getting higher. For cases where the data is really important, >> backup-restore doesn't provide the necessary uptime, and minimum single >> drive performance is needed, it can make sense to want three copies. >> >> But what's the probability of both drives in a mirrored raid set dying, >> compared to something else in the storage stack dying? I think at 3 copies, >> you've got other risks that the 3rd copy doesn't manage, like a power >> supply, controller card, or logic board dying. >> > The risk isn't as much both drives dying at the same time as one dying > during a rebuild of the array, which is more and more likely as drives > get bigger and bigger. Understood. I'm considering a 2nd drive dying during rebuild (from a 1st drive dying) as essentially simultaneous failures. And in the case of raid10, the likelihood of a 2nd drive failure being the lonesome drive in a mirrored set is statistically very unlikely. The next drive to fail is going to be some other drive in the array, which still has a mirror. I'm not saying there's no value in n-way. I'm just saying adding more redundancy only solves on particular vector for failure that's still probably less likely than losing a power supply or a controller or even user induced data loss that ends up affecting all three copies anyway. And yes, it's easier to just add drives and make 3 copies, than it is to setup a cluster. But that's the trade off when using such high density drives that the rebuild times cause consideration of adding even more high density drives to solve the problem. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
