On Wed, 2013-10-23 at 12:44 +0000, Curt wrote: > On 2013-10-23, Ralf Mardorf <[email protected]> wrote: > > > > Isn't that plausible? I'm the source, I care for facts, not for claims > > from vendors. > > >From your favorite company: > > <research.google.com/archive/disk_failures.pdf> > > Power Cycles. The power cycles indicator counts the > number of times a drive is powered up and down. In > a server-class deployment, in which drives are powered > continuously, we do not expect to reach high enough > power cycle counts to see any effects on failure rates. > Our results find that for drives aged up to two years, this > is true, there is no significant correlation between fail- > ures and high power cycles count. But for drives 3 years > and older, higher power cycle counts can increase the > absolute failure rate by over 2%. We believe this is due > more to our population mix than to aging effects. More- > over, this correlation could be the effect (not the cause) > of troubled machines that require many repair iterations > and thus many power cycles to be fixed. > > Power-on hours. Although we do not dispute that > power-on hours might have an effect on drive lifetime, > it happens that in our deployment the age of the drive is > an excellent approximation for that parameter, given that > our drives remain powered on for most of their life time. > > Key findings: > > · Contrary to previously reported results, we found > very little correlation between failure rates and ei- > ther elevated temperature or activity levels. > · Some SMART parameters (scan errors, realloca- > tion counts, offline reallocation counts, and proba- > tional counts) have a large impact on failure proba- > bility. > · Given the lack of occurrence of predictive SMART > signals on a large fraction of failed drives, it is un- > likely that an accurate predictive failure model can > be built based on these signals alone.
Don't confuse 12 Power_Cycle_Count with 193 Load_Cycle_Count -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/1382539226.705.1.camel@archlinux
