Environment
- Linux
- AWS EFS over NFSv4.1
- separate reader and writer clients
Summary
Zoekt maps shard files with MAP_SHARED, closes the descriptor, and publishes replacements over stable shard paths:
Replacing the stable path from another client can remove the last name for the inode behind a live mmap. A later cold-page access then faults, although the replacement shard is valid and loads normally.
Observed sequence
- A reader mapped a valid shard.
- A writer on another client renamed a replacement over the stable path.
- The reader later faulted while accessing its existing mapping.
- Reopening loaded the valid replacement immediately.
Controlled reproduction
A two-client Linux NFS harness mapped a moderate-size file, replaced its stable path from the other client, and repeatedly evicted and reread pages. The stable-path control faulted after hundreds of cold-page cycles.
An immutable-generation variant publishes each shard under a unique path, switches the stable path atomically, holds the reader descriptor and shared lock through munmap, and reclaims retired generations only after a grace period and exclusive lock. It survived tens of thousands of cycles plus explicit cache eviction, deferred reclamation while the reader held the mapping, and reclaimed the retired generation after release.
The local NFS control demonstrates the stale-mmap mechanism, not an exact EFS reproduction.
Relationship to other fixes
#1116 detects same-mtime file replacement but cannot preserve the inode behind an mmap already held by a reader. #1107 and #1108 improve malformed-index validation and error propagation without changing publication lifetime.
Expected behavior
Publishing or retiring a shard must not invalidate mappings held by active searchers. A live mapping's backing object must remain named until no reader can access it.
Environment
Summary
Zoekt maps shard files with
MAP_SHARED, closes the descriptor, and publishes replacements over stable shard paths:NewIndexFileReplacing the stable path from another client can remove the last name for the inode behind a live mmap. A later cold-page access then faults, although the replacement shard is valid and loads normally.
Observed sequence
Controlled reproduction
A two-client Linux NFS harness mapped a moderate-size file, replaced its stable path from the other client, and repeatedly evicted and reread pages. The stable-path control faulted after hundreds of cold-page cycles.
An immutable-generation variant publishes each shard under a unique path, switches the stable path atomically, holds the reader descriptor and shared lock through
munmap, and reclaims retired generations only after a grace period and exclusive lock. It survived tens of thousands of cycles plus explicit cache eviction, deferred reclamation while the reader held the mapping, and reclaimed the retired generation after release.The local NFS control demonstrates the stale-mmap mechanism, not an exact EFS reproduction.
Relationship to other fixes
#1116 detects same-mtime file replacement but cannot preserve the inode behind an mmap already held by a reader. #1107 and #1108 improve malformed-index validation and error propagation without changing publication lifetime.
Expected behavior
Publishing or retiring a shard must not invalidate mappings held by active searchers. A live mapping's backing object must remain named until no reader can access it.