Recent Features
| |||||||||||||
A better btrfsA better btrfsPosted Jan 19, 2008 17:54 UTC (Sat) by giraffedata (subscriber, #1954)In reply to: A better btrfs by Cato Parent article: A better btrfs
if each disk is very likely to have a bad block at any time, as seems more likely to be the case with today's larger disks, then you start to really need RAID, block checksumming, etc, simply to avoid losing data. That risk would be the same if you had 10 disks, each with one tenth the data and one tenth the error rate.
I believe that people are storing more and more data on a given system, and the fact that p(error on this system) is going up should be of concern. Now you're talking about error rate per system, not per disk. And I'm not convinced that's important either. Spreading data out across 10 systems doesn't make the data loss hurt any less.
(Log in to post comments)
A better btrfs Posted Jan 20, 2008 18:08 UTC (Sun) by Cato (subscriber, #7643) [Link] Error rate per system is a better metric as you say - your original post said 'error rate per system administrator' which was a bit confusing.
A better btrfs Posted Jan 20, 2008 20:57 UTC (Sun) by giraffedata (subscriber, #1954) [Link] I think error rate per system is more useful than error rate per disk, but as I said, even error rate per system isn't terribly useful. Error rate per system administrator is considerably more useful.If a major cost of disk errors is a system administrator having to replace a disk, restore from backup, recreate data, etc., then you care how many times a year the system administrator has to do that. Consolidating data from two systems onto one doubles your error rate per system, but doesn't mean you have to increase your RAID redundancy and such because the error rate per system administrator is still the same. On the other hand, piling a terabyte of movies onto the systems managed by a system administrator increases that error rate and might require some new method of dealing with the errors.
|
|||||||||||||