Reduce disk reads on the tiered Vector Set search path

[badrishc]

What

Two changes to the storage-tiered (disk-backed) DiskANN Vector Set read path:

1. Cache the DiskANN Metadata term (copy-to-tail). It previously fell into the default read-copy branch (CopyTo=None) and was re-read from disk on every rerank candidate; it is now copied back to memory after first touch like the other per-node graph records (NeighborList, QuantizedVector, id maps). DiskANNService.Metadata is made internal so the policy can name it.
2. Size the FullVector's initial disk read for a single IO. Widen VectorRecordReadOverheadBytes 64 → 128 so the whole record (RecordInfo + RecordDataHeader + namespace + key + value) lands in one sector-aligned IO. Over-sizing is free here (it rounds to the same sectors as the value alone); under-sizing forces a second IO.

Why

On the disk tier, even though the quantized vectors and graph adjacency are already memory-resident, two records were read from disk once per rerank candidate: the raw FullVector (expected — used for the exact-distance rerank) and the DiskANN Metadata term. The Metadata term is a small, shared structure (~154 records for a 10M graph) but at ~8 KB each and read ~193×/query it accounted for ~73% of disk bytes/query — more bytes than the vectors themselves — purely because it was never cached. Caching it costs ~1.3 MB of memory and removes it from the steady-state disk path entirely.

Impact

Cohere-10M (768-dim, COSINE), Q8, M=16 / l_build=300 / l_search=192 / k=100, warm disk-tiered serial (--storage-tier, Native/O_DIRECT):

metric	before	after
disk reads / query	386	193
disk bytes / query	2,176 KB	594 KB (−73%)
warm serial latency (avg)	86 ms	46.5 ms
disk peak QPS	~223	~1,162
recall@100	0.8408	0.8408 (unchanged)

Tests

Garnet.test.vectorset — the VectorSetRecallSmokeTests (which assert recall survives eviction / copy-to-tail / save+recover across NOQUANT/Q8/BIN) pass on both net8.0 and net10.0; the full vectorset suite is green.

Notes / follow-up (not in this PR)

After this change the sole remaining steady-state disk cost is the FullVector rerank reads. These are currently issued by DiskANN one key at a time (the read callback is invoked with numKeys=1, ~193 serial calls/query), which caps the device queue depth (~30) well below the drive's IOPS ceiling. Garnet's batched-read path (ReadWithPrefetch) already issues reads in parallel for numKeys>1 (it is used for graph traversal today), so batching the rerank GET would be a small, self-contained DiskANN-side change with no Garnet change required — a promising follow-up for a further QPS lift.

[Copilot]

Pull request overview

This PR optimizes the disk-backed DiskANN Vector Set read path by reducing repeated storage-tier disk reads and improving initial disk read sizing for full-vector records.

Changes:

• Cache DiskANN “Metadata” term records via read-copy (copy-to-tail/read-cache) so they are served from memory after first touch.
• Increase VectorRecordReadOverheadBytes (64 → 128) to better ensure a single sector-aligned IO fetches the whole FullVector record.
• Make DiskANNService.Metadata internal so the read-copy policy can reference it.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
libs/server/Resp/Vector/VectorManager.Callbacks.cs	Adds Metadata to the read-copy policy and widens the initial disk-read sizing overhead used for vector-record reads.
libs/server/Resp/Vector/DiskANNService.cs	Exposes the Metadata term constant at internal visibility for use by the vector read-copy policy.

[badrishc]

Good catch — corrected in 2283af6. The comment now states the over-size is free only within the sector-alignment slack (while value+overhead rounds up to the same sectors the full record already occupies); a bump crossing a sector boundary would read an extra sector.