Codex found a kernel edge case where dedupe does update mtime and ctime.
What goes wrong:
- btrfs dedupes in 16 MiB chunks. If the file being kept has a hole (a sparse, never-written region) at the end of a chunk, btrfs punches a matching hole in the other file. It does this through a helper call that doesn't tell the helper this is a dedupe (reflink.c:660-661, the
NULLargument). - That helper works from a small metadata budget. If removing the other file's extents uses it up, the helper goes round a retry loop (file.c:2412, block-rsv.c:94-101).
- The retry loop sets mtime and ctime to "now" unless it was told this is a dedupe (file.c:2496-2498). The comment right above that line says dedupe is supposed t