I am seeing repeated syslog entries like the following:

 

Jul 11 13:10:32 Tower kernel: BTRFS warning (device md3): csum failed root 5 ino 9417 off 0 csum 0xff2f6c6e expected csum 0xfbf6a901 mirror 1

I have run btrfs scrub -BdrR on the disk with the results:

Scrub started:    Mon Jul 13 08:03:48 2020
Status:           finished
Duration:         3:16:01
        data_extents_scrubbed: 30134550
        tree_extents_scrubbed: 253058
        data_bytes_scrubbed: 1973622132736
        tree_bytes_scrubbed: 4146102272
        read_errors: 0
        csum_errors: 4
        verify_errors: 0
        no_csum: 116992
        csum_discards: 0
        super_errors: 0
        malloc_errors: 0
        uncorrectable_errors: 0
        unverified_errors: 0
        corrected_errors: 0
        last_physical: 2018740535296

I checked the contents of the disk for inode 9417 with ls -liR, but find no file with inode 9417.  There is no file associated with the inode that is be reported in the syslog.  

 

Extended SMART self-tests show no errors.  Drive has been powered on for about 1.5 years.

 

An explanation of what I am missing here and suggested next steps would greatly be appreciated.

Run a scrub, any corrupt files will be identified on the syslog during it.

Thanks for the info johnnie.  I never did find what was at inode 9417.  I have run a scrub again and this time the filenames were in the log - two .DS_Store files.  

 

No big loss, but increasing checksum errors, all on the same disk are. I'm going to swap the drive out ASAP.

12 hours ago, CarpNCod said:

I have run a scrub again and this time the filenames were in the log

Scrub should always output the affected filenames to the log, it won't be on the log when a checksum error is detected during a normal file read, just the error without the filename.

I see now why I didn't see the filename in the syslog -- I had run the btrfs scrub from the command line, rather than running it from within the GUI.  I am still getting used to btrfs after having run reiserfs for so long.  

 

Having said that, running ls -laiR /mnt/disk3 | grep 9417 should have shown me the filename associated with inode 9417.

 

Lesson learned.  I'll run the scrub from the GUI from now on to capture the filename in the syslog.

 

37 minutes ago, CarpNCod said:

I had run the btrfs scrub from the command line

That won't matter, it will still show any errors and the filenames on the syslog, just when you try to access the file it shows the checksum error but not the filename.

 

 

I have pre-cleared a new disk, and replaced disk3 that was incrementing errors.  So far, it looks like all is right with the world again.

 

Going forward, if I get anymore BTRFS warning csum failed messages, I will run a scrub from the GUI, and then check the syslog for the impacted file before proceeding.