Recovery Oriented Computing (ROC): Motivation, Definition, Techniques, and Case Studies
David Patterson and Aaron Brown and Pete Broadwell and George Candea and Mike Chen and James Cutler and Patricia Enriquez and Armando Fox and Emre Kiciman and Matthew Merzbacher and David Oppenheimer and Naveen Sastry and William Tetzlaff and Jonathan Traupman and Noah Treuhaft
EECS Department, University of California, Berkeley
Technical Report No. UCB/CSD-02-1175
, 2002
http://www2.eecs.berkeley.edu/Pubs/TechRpts/2002/CSD-02-1175.pdf
It is time to broaden our performance-dominated research agenda. A four order of magnitude increase in performance since the first ASPLOS in 1982 means that few outside CS&E research community believe that speed is the only problem of computer hardware and software. Current systems crash and freeze so frequently that people become violent. Fast but flaky should not be our 21st century legacy. <p>Recovery Oriented Computing (ROC) takes the perspective that hardware faults, software bugs, and operator errors are facts to be coped with, not problems to be solved. By concentrating on Mean Time to Repair (MTTR) rather than Mean Time to Failure (MTTF), ROC reduces recovery time and thus offers higher availability. Since a large portion of system administration is dealing with failures, ROC may also reduce total cost of ownership. One to two orders of magnitude reduction in cost mean that the purchase price of hardware and software is now a small part of the total cost of ownership. <p>In addition to giving the motivation and definition of ROC, we introduce failure data for Internet sites that shows that the leading cause of outages is operator error. We also demonstrate five ROC techniques in five case studies, which we hope will influence designers of architectures and operating systems. <p>If we embrace availability and maintainability, systems of the future may compete on recovery performance rather than just SPEC performance, and on total cost of ownership rather than just system price. Such a change may restore our pride in the architectures and operating systems we craft.
BibTeX citation:
@techreport{Patterson:CSD-02-1175, Author= {Patterson, David and Brown, Aaron and Broadwell, Pete and Candea, George and Chen, Mike and Cutler, James and Enriquez, Patricia and Fox, Armando and Kiciman, Emre and Merzbacher, Matthew and Oppenheimer, David and Sastry, Naveen and Tetzlaff, William and Traupman, Jonathan and Treuhaft, Noah}, Title= {Recovery Oriented Computing (ROC): Motivation, Definition, Techniques, and Case Studies}, Year= {2002}, Month= {Mar}, Url= {http://www2.eecs.berkeley.edu/Pubs/TechRpts/2002/5574.html}, Number= {UCB/CSD-02-1175}, Abstract= {It is time to broaden our performance-dominated research agenda. A four order of magnitude increase in performance since the first ASPLOS in 1982 means that few outside CS&E research community believe that speed is the only problem of computer hardware and software. Current systems crash and freeze so frequently that people become violent. Fast but flaky should not be our 21st century legacy. <p>Recovery Oriented Computing (ROC) takes the perspective that hardware faults, software bugs, and operator errors are facts to be coped with, not problems to be solved. By concentrating on Mean Time to Repair (MTTR) rather than Mean Time to Failure (MTTF), ROC reduces recovery time and thus offers higher availability. Since a large portion of system administration is dealing with failures, ROC may also reduce total cost of ownership. One to two orders of magnitude reduction in cost mean that the purchase price of hardware and software is now a small part of the total cost of ownership. <p>In addition to giving the motivation and definition of ROC, we introduce failure data for Internet sites that shows that the leading cause of outages is operator error. We also demonstrate five ROC techniques in five case studies, which we hope will influence designers of architectures and operating systems. <p>If we embrace availability and maintainability, systems of the future may compete on recovery performance rather than just SPEC performance, and on total cost of ownership rather than just system price. Such a change may restore our pride in the architectures and operating systems we craft.}, }
EndNote citation:
%0 Report %A Patterson, David %A Brown, Aaron %A Broadwell, Pete %A Candea, George %A Chen, Mike %A Cutler, James %A Enriquez, Patricia %A Fox, Armando %A Kiciman, Emre %A Merzbacher, Matthew %A Oppenheimer, David %A Sastry, Naveen %A Tetzlaff, William %A Traupman, Jonathan %A Treuhaft, Noah %T Recovery Oriented Computing (ROC): Motivation, Definition, Techniques, and Case Studies %I EECS Department, University of California, Berkeley %D 2002 %@ UCB/CSD-02-1175 %U http://www2.eecs.berkeley.edu/Pubs/TechRpts/2002/5574.html %F Patterson:CSD-02-1175