I used two disks to create a btrfs raid 1 mirror, and after adding a bunch of files I ran a scrub. The command btrfs scrub status <dir> reports that it finished with 0 errors. However, btrfs scrub status -R <dir> displays:

data_extents_scrubbed: 13887259
tree_extents_scrubbed: 61886
data_bytes_scrubbed: 906996514816
tree_bytes_scrubbed: 1013940224
read_errors: 0
csum_errors: 0
verify_errors: 0
no_csum: 54400
csum_discards: 0
super_errors: 0
malloc_errors: 0
uncorrectable_errors: 0
unverified_errors: 0
corrected_errors: 0
last_physical: 912854614016

Particularly, the no_csum value looks a bit concerning. Would this cause a problem if btrfs ever needed to repair any data, or is this fine and expected?

  • In my case it was no_csum: 4179778 in a RAID1 with 878.33GiB of data. Also wondering if I should be worried.
    – Falk
    Jan 27, 2020 at 17:09
  • Here is a discussion which tries to explain this: spinics.net/lists/linux-btrfs/msg31952.html seems to be related to the free space cache, which is not checksummed since it can be recovered if it gets corrupted
    Nov 3, 2020 at 11:15

1 Answer 1


no_csum, or absence of checksum means number of files where checksum calculation cannot be applied. Checksums calculation can be disabled for files, directories or partitions using attributes nodatasum or nodatacow.

Additionally, it is worth to take a look at the discussion in BTRFS mailing list which @SIGSEGV has mentioned in the comments. BTRFS uses free space cache, which is nodatacow by design and it is counted by btrfs scrub command.

You must log in to answer this question.

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