On Wed, Mar 3, 2021 at 5:34 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Mar 03, 2021 at 04:57:28PM -0700, Chris Murphy wrote:
It works at the block level. A block is read, checksum calculated and compared to the previously recorded checksum for the block. It doesn't know what it's reading, not even whether it's compressed or not. It just becomes a stream of blocks without respect to the file or subvolume. If there's a mismatch, then it does a lookup to find out the owner: what subvolume/snapshot and filename/inode, what offset, and so on - which is then how it figures out where the good copy is (if any) and does self-healing. It pretty much runs at device max read capability.
So given this, even with atimes there's only a write in the case where there's a mismatch, right?
If there's a mismatch, and no redundancy, there's no fixup. Therefore no write.
If there's a mismatch, and there's redundancy of some kind, a fixup is possible. That involves finding the good copy and overwriting the bad. But this too is at a block level, and atime is not touched. Btrfs scrub is a process that works within the file system, it's not user space so there's no file access happening at all.