Optimize fetch_entries_to function to avoid stucking write too long.

[LykxSassinator]

Background

PR #370 fixed a panic issue caused by concurrent updates to Memtable followed by reads on stale indexes. However, we observed that this fix introduced performance regressions under concurrent read/write workloads.

Issue

When fetch_entries_to retrieves a large batch of entries from disk, write operations are blocked until the read completes, delaying Memtable updates and degrading throughput.

Solution

This PR optimizes fetch_entries_to to reduce contention and improve performance under mixed workloads.

Results

Branch	Status
Master
This PR

[ti-chi-bot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[glorv]

Can we ensure the safety to read entry without holding the lock? Is it possible that some entries are truncated and target wal files are Gced(or reused) before this read, then the result of this read is undefined behavior

[LykxSassinator]

Yep. It's ensured.

Is it possible that some entries are truncated and target wal files are Gced(or reused) before this read

• File Access Atomicity in Raft-Engine
  In raft-engine, file access (.raftlog) is atomic. The GC operation acquires a mutex and deletes the entire file before allowing other accesses. If a read operation successfully returns the target bytes, the result is guaranteed valid.

• Index Consistency Handling
  This PR further ensures consistency by returning Error(e) if the Memtable index is updated (by either background rewrite or foreground write threads) during a read. Then it will automatically retry with the latest index to fetch the correct entry bytes.

[glorv]

Index Consistency Handling

Say if an entry is rewritten and the old wal file is purged before the real access, seems we still can read it with the old entry info as the file handle is changed then seems we still returns an error even if the entay is actually vaild.

[LykxSassinator]

If it uses a stale file handle to get the entry, it will get the Error(OutOfSeq), ref:
https://github.com/LykxSassinator/raft-engine/blob/392f5e66f8286dc1b6d7cf69f2bc20ed72d40123/src/file_pipe_log/pipe.rs#L238

So, if the first fetch uses a stale index to get the entry, it will return an Error and trigger the second retry, where it will use the latest index to access the entry.

[glorv]

LGTM

[overvenus]

Rest LGTM

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: glorv, overvenus

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [glorv,overvenus]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2025-07-03 07:36:16.133028097 +0000 UTC m=+1553228.856207081: ☑️ agreed by glorv.
• 2025-07-04 08:22:18.919925679 +0000 UTC m=+1642391.643104660: ☑️ agreed by overvenus.