10.01.2020 02:50, Philip Seeger пишет: >> On 2020-01-09 13:04, Nikolay Borisov wrote: >>> It seems there are other error codes which are >>> also ignored but can signify errors e.g. STS_NEXUS/STS_TRANSPORT. > > Speaking of other errors also being ignored. > > I just saw this on a different system: > > BTRFS warning (device sdd1): csum failed root 5 ino 263 off 5869793280 > csum 0xeee8ab75 expected csum 0x1fc62249 mirror 1 > > Is BTRFS trying to tell me that the file with inode number 263 is > corrupt (checksum mismatch)? > I did indeed read (copy) that file earlier so it sounds like BTRFS > calculated its checksum to verify it and it didn't match the stored > checksum. > On one mirror piece. It likely got correct data from another piece. > The error counters returned by "dev stats" all stayed at 0 (even after > scrubbing). This is (was) a single filesystem, no RAID. > This is not device-level error. btrfs got data from block device without error. That content of data was wrong does not necessarily mean block device problem. > Suppose this was an important file, should I be worried now? > You have mirror and btrfs got correct data from another device (otherwise you were not able to read file at all). Of course you should be worried why one copy of data was not correct. > If this was a checksum error, why does the stats command keep saying > that zero errors have been detected? Again - there was no error *reading* data from block device. Is corruption_errs also zero?
