Re: How to replace a failing device

[Roman Mamedov <rm@romanrm.net>]

On Thu, 03 Nov 2022 14:39:14 -0700
Matt Huszagh <huszaghmatt@gmail.com> wrote:

> I was able to run btrfs scrub successfully with the problematic drive
> removed. Logs show that the following file has a checksum error:
> 
> BTRFS warning (device dm-0): checksum error at logical 10087829524480 on dev /dev/dm-4, physical 1883324207104, root 28842, inode 27543115, offset 74526720, length 4096, links 1 (path: matt/.recoll/library/xapiandb/docdata.glass)
> 
> What can I do to get BTRFS to no longer report a checksum error? Do I
> need to delete this along with all snapshots that contain it?

I believe that's one way, yes; or truncate it to zero bytes, or fully
overwrite with its copy from a backup.

> Ok, thanks for the input. But in theory, BTRFS with a redundant data
> RAID (such as RAID1 or RAID10) should allow scrub to preserve all data
> if a single drive fails, no?

It could, what I meant is that the experience you get while having a disk
failure does not seem polished enough.

For a start, it will cease to mount, and will require adding a "degraded"
mount option. Then, newly written data may get a "single" data profile, and
mounting with "degraded" the second time may fail. To work-around this you
could use the "ro" mount option as well, except that now FS-level operations
like adding or replacing a device will not work. How does one get out of this,
I am not entirely sure.

And there were some reports of bad experience with a disk failure during
normal operation (i.e. device going away, or starting to fail reads or
writes). In theory a RAID system should barely notice such an event, and let
the user smoothly disconnect and pop-in a replacement drive, then continue
working, not to mention without even a reboot. But from the general impression
from user reports, in Btrfs that currently stays only a theory at best.

-- 
With respect,
Roman