Re: How to replace a failing device

[Matt Huszagh <huszaghmatt@gmail.com>]

Roman Mamedov <rm@romanrm.net> writes:

> If your backup is incremental and only copies modified files, you can ensure
> all other files are also readable by recursively reading them:
>
>   find -type f -print0 | xargs -0 cat > /dev/null
>
> ...for a kind of manual scrub. Unless you had nocow/nodatasum files in there,
> any damaged ones will return a read error thanks to Btrfs checksums.
>
> Or maybe you could check if Btrfs scrub has also stopped hanging, given there
> are no disk-level unreadable sectors anymore. (And after you have also
> upgraded the kernel).

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?

> Btrfs currently does not seem to be famous for smooth disk replacements
> unfortunately, even if you would use RAID.
>
> I would suggest keeping up with the good backup schedule, and then rather than
> using the Btrfs "single" profile stretched across devices, switch to MergerFS.
> That way any disaster on a particular disk leaves other disks and their
> independent filesystems completely unaffected.

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?

I'll spend some time looking at mergerfs.

Matt