Documentation/admin-guide/RAS/main.rst

Source file repositories/reference/linux-study-clean/Documentation/admin-guide/RAS/main.rst

File Facts

System
Linux kernel
Corpus path
Documentation/admin-guide/RAS/main.rst
Extension
.rst
Size
39172 bytes
Lines
1088
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>

==================================================
Reliability, Availability and Serviceability (RAS)
==================================================

This documents different aspects of the RAS functionality present in the
kernel.

RAS concepts
************

Reliability, Availability and Serviceability (RAS) is a concept used on
servers meant to measure their robustness.

Reliability
  is the probability that a system will produce correct outputs.

  * Generally measured as Mean Time Between Failures (MTBF)
  * Enhanced by features that help to avoid, detect and repair hardware faults

Availability
  is the probability that a system is operational at a given time

  * Generally measured as a percentage of downtime per a period of time
  * Often uses mechanisms to detect and correct hardware faults in
    runtime;

Serviceability (or maintainability)
  is the simplicity and speed with which a system can be repaired or
  maintained

  * Generally measured on Mean Time Between Repair (MTBR)

Improving RAS
-------------

In order to reduce systems downtime, a system should be capable of detecting
hardware errors, and, when possible correcting them in runtime. It should
also provide mechanisms to detect hardware degradation, in order to warn
the system administrator to take the action of replacing a component before
it causes data loss or system downtime.

Among the monitoring measures, the most usual ones include:

* CPU – detect errors at instruction execution and at L1/L2/L3 caches;
* Memory – add error correction logic (ECC) to detect and correct errors;
* I/O – add CRC checksums for transferred data;
* Storage – RAID, journal file systems, checksums,
  Self-Monitoring, Analysis and Reporting Technology (SMART).

By monitoring the number of occurrences of error detections, it is possible
to identify if the probability of hardware errors is increasing, and, on such
case, do a preventive maintenance to replace a degraded component while
those errors are correctable.

Types of errors
---------------

Most mechanisms used on modern systems use technologies like Hamming
Codes that allow error correction when the number of errors on a bit packet
is below a threshold. If the number of errors is above, those mechanisms
can indicate with a high degree of confidence that an error happened, but
they can't correct.

Also, sometimes an error occur on a component that it is not used. For
example, a part of the memory that it is not currently allocated.

That defines some categories of errors:

Annotation

Implementation Notes