Recovery Oriented Computing (ROC): Motivation, Definition, Techniques, and Case Studies

David Patterson, Aaron Brown, Pete Broadwell, George Candea, Mike Chen, James Cutler, Patricia Enriquez, Armando Fox, Emre Kiciman, Matthew Merzbacher, David Oppenheimer, Naveen Sastry, William Tetzlaff, Jonathan Traupman and Noah Treuhaft

EECS Department
University of California, Berkeley
Technical Report No. UCB/CSD-02-1175
March 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.

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.

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.

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},
    Institution = {EECS Department, University of California, Berkeley},
    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