Local Caching

[markovejnovic]

No description provided.

[mesa-dot-dev]

Mesa Description

This PR introduces a local caching layer for the filesystem to improve performance and reduce latency for cloud operations.

This caching layer acts as a "write-through" cache, meaning that write operations will update both the local cache and the backing cloud storage. This ensures data consistency while allowing subsequent read operations to be served directly from the faster local cache.

Key changes include:

• A new icache module to handle the caching of filesystem inodes.
• The WriteThrough filesystem implementation that orchestrates the caching logic.
• Integration of the caching layer into the mescloud composite filesystem.

^{Description generated by Mesa. Update settings}

[mesa-dot-dev]

Performed full review of f6fed08...e0ff702

Analysis

1. Cache correctness issue: The background cache population mechanism must ensure only complete files are stored, which may require careful synchronization or verification.

2. Eviction coordination risk: There's a potential for misalignment between CacheTracker and AsyncICache during cache eviction, which could lead to orphaned entries or reference inconsistencies.

3. Reproducibility concern: The reusable workflow action needs proper templated inputs to maintain release reproducibility across different environments.

4. Architecture complexity: The shift to a pluggable caching architecture introduces additional abstraction layers and composition points that may increase debugging difficulty.

Tip

Help

Slash Commands:

• /review - Request a full code review
• /review latest - Review only changes since the last review
• /describe - Generate PR description. This will update the PR body or issue comment depending on your configuration
• /help - Get help with Mesa commands and configuration options

^{0 files reviewed | 1 comments | Edit Agent Settings • Read Docs}

[mesa-dot-dev]

Populating the cache whenever offset == 0 still caches whatever slice the backend returned for that first read. The kernel almost always issues the first read at offset 0 with a fixed chunk size (e.g. 128 KB), so we end up writing just that chunk to the cache and then advertising it as the full file. Subsequent reads at higher offsets (https://github.com/mesa-dot-dev/git-fs/blob/HEAD/src/fs/write_through.rs#L172-L177) will hit the truncated cache entry, get an empty slice, and stop reading early, so large files appear to be cut off at the first chunk once cached.

We should only populate the cache when we know we have the full file (e.g. compare the returned length against the file’s actual size, or buffer until EOF) instead of caching every offset‑0 read.

 • 

Prompt for Agent

Task: Address review feedback left on GitHub.
Repository: mesa-dot-dev/gitfs#37
File: src/fs/write_through.rs#L185
Action: Open this file location in your editor, inspect the highlighted code, and resolve the issue described below.

Feedback:
Populating the cache whenever `offset == 0` still caches whatever *slice* the backend returned for that first read. The kernel almost always issues the first read at offset 0 with a fixed chunk size (e.g. 128 KB), so we end up writing just that chunk to the cache and then advertising it as the full file. Subsequent reads at higher offsets (<https://github.com/mesa-dot-dev/git-fs/blob/HEAD/src/fs/write_through.rs#L172-L177>) will hit the truncated cache entry, get an empty slice, and stop reading early, so large files appear to be cut off at the first chunk once cached.

We should only populate the cache when we know we have the full file (e.g. compare the returned length against the file’s actual size, or buffer until EOF) instead of caching every offset‑0 read.