From 499a0493b3f7c2f23a998fa75d6a8764ee4729fe Mon Sep 17 00:00:00 2001 From: "(@silopolis)" <(@silopolis)> Date: Wed, 23 Oct 2024 09:49:47 +0000 Subject: [PATCH] btrfs-progs: docs: auto-repair editing --- Documentation/Auto-repair.rst | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/Documentation/Auto-repair.rst b/Documentation/Auto-repair.rst index 0fb6b6d44d..5b682a260c 100644 --- a/Documentation/Auto-repair.rst +++ b/Documentation/Auto-repair.rst @@ -1,14 +1,16 @@ Auto-repair on read =================== -Data or metadata that are found to be damaged (e.g. because the checksum does -not match) at the time they're read from a device can be salvaged in case the -filesystem has another valid copy when using block group profile with redundancy -(DUP, RAID1-like, RAID5/6). The correct data are returned to the user application -and the damaged copy is replaced by it. When this happen a message is emitted -to the system log. - -If there are more copies of data and one of them is damaged but not read by -user application then this is not detected. To verify all data and metadata -copies there's :doc:`scrub` that needs to be started manually, automatic -repairs happens in that case. +If data or metadata that are found to be damaged at the time they’re read from a device, +for example because the checksum does not match, they can be salvaged if the filesystem +has another valid copy. This can be achieved by using a block group profile with redundancy +like `DUP`, RAID1-like, or RAID5/6. + +The correct data is returned to the user application and the damaged copy is replaced by it. +When this happens, a message is emitted to the system log. + +If there are multiple copies of data and one of them is damaged but not read by the user +application, then this is not detected. + +To ensure the verification and automatic repair of all data and metadata copies, the +:doc:`scrub` operation must be initiated manually.