scan_next: detect snapshot families for the sharing cost model
Undiverged snapshots share metadata pages, so k refs to the same
(inode, offset) through k subvols of one snapshot family are one
physical metadata item, not k items. The space-debt model needs to
know which subvols can share pages — and with which other subvols,
since grouping refs by (inode, offset) is only sound within one
family.
Add scan_next_snap_cluster_map(): union-find over root_item uuid
values, joining each subvol's uuid to its nonzero parent_uuid.
Joining uuid values rather than subvols makes the sibling rule
automatic — two children of a deleted parent meet at the parent's
uuid with no surviving subvol needed. Only families with two or more
existing members are published (root id -> lowest member root id), so
a no-snapshots filesystem carries one empty map. A deleted middle
link in a snapshot-of-a-snapshot chain breaks the join; accepted,
since real topologies are stars or rolling chains where the last two
generations coexist. scan_next_snap_extra() computes the resulting
undercharge: sum of (k - 1) over groups of identical (cluster, inode,
offset) keys.
Expose the map through the extent layer as snap_cluster(root):
default 0 (no families), btrfs base builds it lazily from one
ROOT_ITEM sweep under its own mutex and bulk-clears it at transid
change (snapshot create/delete only becomes visible at a commit, so
per-transid granularity is exact), overlay delegates to its parent.
Both helpers are layer-free and pinned by unit tests covering the
star, orphan-sibling, sole-survivor, chain, deleted-middle,
independent-family, and legacy zero-uuid cases.
projects / bees / commit