On Wed, Mar 3, 2021 at 5:34 PM Matthew Miller <mattdm(a)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.
--
Chris Murphy