Struct ReadOnlyEdgeShard 

pub struct ReadOnlyEdgeShard<S: UniversalReadExt + 'static> { /* private fields */ }

Read-only follower view over an edge shard’s on-disk directory.

Generic over the read backend S (e.g. MmapFile for local memory-mapped files; the same abstraction ReadOnlySegment uses, so blob/S3 backends are possible). Use open_mmap for the common local case.

Implementations

impl ReadOnlyEdgeShard<MmapFile>

pub fn open_mmap(path: &Path) -> OperationResult<Self>

Open a read-only follower over local memory-mapped files, discovering segments from the leader’s segment manifest. Requires the leader to write a manifest (the write_segment_manifest feature flag).

impl<S: UniversalReadExt + 'static> ReadOnlyEdgeShard<S>

pub fn open( fs: S::Fs, path: &Path, config: Option<EdgeConfig>, load_profile: Option<LoadProfile>, ) -> OperationResult<Self>

where S::Fs: Send + Sync + Clone + 'static,

Open a read-only follower over the edge-shard directory at path using read backend fs.

Segments are discovered through the leader’s segment manifest (read via fs) — a read-only follower always uses the manifest, so there is no discovery to configure.

A follower has no edge_config.json — the segments are the source of truth, so the config is derived from the segments themselves (see EdgeConfig::from_segment_config), mirroring the read-write EdgeShard’s fallback. A provided config overrides tunable parameters at open (its Some values win over the derived ones; vectors/sparse_vectors are ignored); a refresh re-derives the config from the segments alone. An empty shard (no segments yet) starts from the provided config (or a default one).

A load_profile — derived from the request this shard is being opened to serve (see LoadProfile) — parks the segment components that request won’t touch cold instead of warming them per the persisted segment configs, cutting the cold-start cost. Without one, loading follows the segment configs alone. The profile also applies to segments a later refresh discovers: the shard was opened for that one request, so new segments shouldn’t load any warmer.

impl<S: UniversalReadExt + 'static> ReadOnlyEdgeShard<S>

pub fn refresh(&self) -> OperationResult<()>

where S::Fs: Send + Sync + Clone + 'static,

Refresh the follower to the leader’s current on-disk state.

Caller-driven (never self-triggered), mirroring ReadOnlySegment::live_reload: the host owns the cadence (a timer, an explicit call after a known leader flush, or an FS watch). Eventually consistent — a point becomes visible once the leader has flushed it to the segment files and a subsequent refresh has run.

Leader-side segment churn is absorbed: a segment whose files vanish while its live-reload runs is checked against a re-read manifest, and if the leader indeed removed it, the segment is dropped and the refresh re-runs (bounded) to pick up its replacements. Err therefore means the shard genuinely needs attention: a component failed to reload, or a segment’s essential files are missing while the manifest still lists it. Either way the shard stays consistent — every swap is atomic, a failed segment keeps serving its pre-refresh state, and the next refresh replays its unapplied delta (see pending_reload).

pub fn refresh_with( &self, hw_counter: &HardwareCounterCell, ) -> OperationResult<()>

where S::Fs: Send + Sync + Clone + 'static,

refresh with a caller-supplied hardware counter.

impl<S: UniversalReadExt + 'static> ReadOnlyEdgeShard<S>

pub fn path(&self) -> &Path

pub fn segments_count(&self) -> usize

Number of segments currently open in the follower.