On Wed, Mar 3, 2021 at 5:34 PM Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> 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 _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
