---
title: Deduplication
description: How Kache shares output bytes and restores them safely
---
Kache saves disk in two independent places: inside the store and between the store and build trees.
## Content-addressed blobs
Each output blob is named by its BLAKE3 content hash:
```text
<cache-dir>/store/blobs/ab/abcdef...
```
Entries refer to blobs through metadata and the SQLite index. Identical bytes share one blob even when they came from different cache keys. Garbage collection removes a blob only after no entry needs it.
## Restore methods
Kache uses the first of these methods that applies to an artifact:
1. copy-on-write clone on APFS, ReFS, btrfs, or reflink-capable XFS
2. one exclusive Unix hardlink carrier for immutable `.rlib` and `.rmeta` artifacts, and on Linux for proc-macro libraries and build-script binaries
3. byte copy
Other executable and loadable outputs use clone or copy, never the hardlink fallback, because signing, stripping, or another consumer may modify them. On Linux, proc-macro libraries and build-script binaries share the blob's inode when the blob is read-only and executable, since nothing rewrites them after a restore. A blob without every execute bit, such as one imported from a remote cache, is copied. Windows copies on non-CoW volumes unless the unsafe `windows_hardlink` option is enabled.
Restored reflinks and copies are writable by their owner, so a later compiler invocation can overwrite them after you remove the Kache wrapper. Adding owner write access to a reflink preserves its other permissions and leaves the cache blob read-only. A hardlink carrier shares permissions with the blob and stays read-only; rebuilding those outputs without Kache can require removing them first.
Reflinks have independent inodes. A later write copies changed blocks instead of modifying the store blob.
## Monitor metrics
The monitor's Store tab shows registered blob bytes and the share of logical
size saved by sharing. While Projects is walking target directories, that tab
says `scanning…`.
In `kache stats`, Cache and Store show registered blob bytes; Limit is the
registered blob budget. Dedup shows logical output bytes and the percentage
saved. If blob inventory is unavailable, the size is labeled as logical.
Registered bytes describe the cache's index, rather than all space allocated
on disk or the additional blocks occupied by restored worktrees.
Run `kache clean --dry-run` to see what deleting each target directory frees and which ones a clean would remove.
## `dup` build events
A `dup` event means the cache key missed, the compiler ran, and all resulting blobs were already present. It is not a restore, and it is separate from the `Dedup` metric. Repeated dups can expose noisy or over-specific key inputs.