3

TL;DR: Two disks in raid1 using btrfs. Checksums are only verified for the disk from which the file data was read. How to force verifying all checksums occasionally, e.g. in a weekly cron?


I have a btrfs on 2 disks in raid1 (/dev/sd{b,c}1). To test error correction, I wrote a file to disk, looked up in which sector it was stored, and changed a single bit by writing directly to /dev/sdc1. Since I mounted /dev/sdb1, I figured writing to /dev/sdc1 would be a good test to see whether it replicated at all, and whether it would detect the change.

When reading the file, no errors occurred and the changed bit was still present in sdc1 (it was not present in sdb1). It took until unmounting sdb1 and mounting sdc1 instead, then reading the file, for the error to be corrected.

How can I regularly verify checksums (for example weekly, using cron) on both disks without having to unmount?

If you want to replicate the situation, this is what I did:

$ mount /dev/sdb1 /mnt && cd /mnt
$ yes | head -100 > yes
$ filefrag -e yes # Look up in which sector the file is stored
$ echo x | dd of=/dev/sdc seek=$((offset*4096)) bs=1 count=1 # offset*sector_size

$ grep x yes # no results, no errors
$ dmesg | tail # nothing relevant
$ dd if=/dev/sdc skip=$((offset*4096)) bs=1 count=10 # To verify the x is actually there, and it is

$ # Mount sdc1 instead of sdb1
$ cd .. && umount mnt && mount /dev/sdc1 mnt
$ grep x yes # no results, no errors
$ dmesg | tail
[3695509.439534] BTRFS warning (device sdc1): csum failed ino 466 off 469331968 csum 444003100 expected csum 3637724482
[3695509.555018] BTRFS warning (device sdc1): csum failed ino 466 off 469331968 csum 444003100 expected csum 3637724482
[3695509.590762] BTRFS info (device sdc1): read error corrected: ino 466 off 469331968 (dev /dev/sdc1 sector 3692728)
# Finally, it was detected and silently corrected

I'm on kernel version 4.9.

1 Answer 1

4

btrfs scrub fills this role:

btrfs scrub is used to scrub a btrfs filesystem, which will read all data and metadata blocks from all devices and verify checksums. Automatically repair corrupted blocks if there’s a correct copy available.

It's only useful on a btrfs RAID setup such as yours (or a DUP setup perhaps), since it needs another copy to correct against. It's often suggested to run this as a service on a timer. The man page suggests every month as a default, but it can be done more often.

2
  • From the man page: "The IO priority class is by default idle so background scrub should not interfere with normal filesystem operation significantly." This is perfect, thanks!
    – Luc
    Commented Apr 20, 2017 at 12:43
  • 1
    @etskinner my understanding is that scrub is still useful on a single disk filesystem as the checksums can still tell you if there is data corruption even if it can't be repaired.
    – Tom Wadley
    Commented Apr 24, 2022 at 19:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .