<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>codemac</author><text>&amp;#62; That said, if you&apos;re careful then that predictability should be a good thing.&lt;p&gt;Yes, it&apos;s a very good thing. In a high end SSD storage system, you predict early enough based on a calculation of how many drives there are, and what their current wear is, what type they are (SLC, eMLC, cMLC), etc. Then you phone home and have a drive delivered before the user even sees a disk failure.&lt;p&gt;With HDD&apos;s, the failure rate is so random that the disk &lt;i&gt;completely failing&lt;/i&gt; is the signal that get&apos;s a replacement drive into the enclosure. S.M.A.R.T-type alert systems have been epic failures (too little info too late). The difference is because of the RAID rebuild having a lower probability of failure (let&apos;s set aside mulitple URE&apos;s for a second) that you can count on the mttf of the next drive failing being longer than the time it takes to get a drive out there.&lt;p&gt;However this is not much of a guarantee, so most people crazy over provision their storage.&lt;p&gt;SSDs let you predict this, thus provision correctly, and choose how to replace the drives to least impact the customer. It&apos;s win win to have predictable failure. I don&apos;t understand people who say otherwise.</text><parent_chain><item><author>bunderbunder</author><text>&lt;i&gt;Wear patterns and flash are an issue, although rotational drives fail too. There are several answers. When a flash drive fails, you can still read the data. A clustered database and multiple copies of the data, you gain reliability – a server level of RAID. As drives fail, you replace them.&lt;/i&gt;&lt;p&gt;Unlike magnetic disks, SSDs have a tendency to fail at a really predictable rate.  So predictably that if you&apos;ve got two drives of the same model, put them into commission at the same time, and subject them to the same usage patterns, they will probably fail at about the same time.  That&apos;s a real problem if you&apos;re using SSDs in a RAID array, since RAID&apos;s increased reliability relies on the assumption that it&apos;s very unlikely for two drives to fail at about the same time.&lt;p&gt;With an SSD, though, once one drive goes there&apos;s a decent (perhaps small, but far from negligible) chance that a second drive will go out before you&apos;ve had a chance to replace the first one.  Which makes things complicated, but is much better than the similarly likely scenario that a second SSD fails shortly after you replace the first one.  Because then it&apos;s possibly happening during the rebuild, and if that happens then it really will bring down the whole RAID array.&lt;p&gt;That said, if you&apos;re careful then that predictability should be a good thing.  A good SSD will keep track of wear for you. So all you&apos;ve got to do is monitor the status of the drives, and replace them before they get too close to their rated lifespan.  If you add that extra step you&apos;re probably actually improving your RAID&apos;s reliability.  But if you treat your RAID as if SSDs are just fast HDDs, you&apos;re asking for trouble.</text></item></parent_chain></comment><story><title>Switch Your Databases To Flash Storage</title><url>http://highscalability.com/blog/2012/12/10/switch-your-databases-to-flash-storage-now-or-youre-doing-it.html</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>baruch</author><text>Assuming this predictability is not a good idea in my experience. SSDs fail in various ways, some may be predictable and some are completely unpredictable. It is also not true that an ssd failure means it simply goes to readonly mode. I&apos;ve seen plenty of SSDs failing unexpectedly and are no longer readable, returning sense key 0x4 (HARDWARE ERROR) and the only recourse is to ship them out.&lt;p&gt;The risk of correlated failures is indeed non-trivial in SSDs and plain RAID is riskier, be sure to keep a watchful eye on your arrays.</text><parent_chain><item><author>bunderbunder</author><text>&lt;i&gt;Wear patterns and flash are an issue, although rotational drives fail too. There are several answers. When a flash drive fails, you can still read the data. A clustered database and multiple copies of the data, you gain reliability – a server level of RAID. As drives fail, you replace them.&lt;/i&gt;&lt;p&gt;Unlike magnetic disks, SSDs have a tendency to fail at a really predictable rate.  So predictably that if you&apos;ve got two drives of the same model, put them into commission at the same time, and subject them to the same usage patterns, they will probably fail at about the same time.  That&apos;s a real problem if you&apos;re using SSDs in a RAID array, since RAID&apos;s increased reliability relies on the assumption that it&apos;s very unlikely for two drives to fail at about the same time.&lt;p&gt;With an SSD, though, once one drive goes there&apos;s a decent (perhaps small, but far from negligible) chance that a second drive will go out before you&apos;ve had a chance to replace the first one.  Which makes things complicated, but is much better than the similarly likely scenario that a second SSD fails shortly after you replace the first one.  Because then it&apos;s possibly happening during the rebuild, and if that happens then it really will bring down the whole RAID array.&lt;p&gt;That said, if you&apos;re careful then that predictability should be a good thing.  A good SSD will keep track of wear for you. So all you&apos;ve got to do is monitor the status of the drives, and replace them before they get too close to their rated lifespan.  If you add that extra step you&apos;re probably actually improving your RAID&apos;s reliability.  But if you treat your RAID as if SSDs are just fast HDDs, you&apos;re asking for trouble.</text></item></parent_chain></comment><story><title>Switch Your Databases To Flash Storage</title><url>http://highscalability.com/blog/2012/12/10/switch-your-databases-to-flash-storage-now-or-youre-doing-it.html</url></story>