What Should a Cache Remember After It Forgets Your Data?

Small verified reads from existing encrypted files, and the case for giving verification metadata its own place in the cache

Abstract

MirageSSD is an open-source storage project. On Windows, it presents cloud-backed files through a drive letter in File Explorer, keeps selected data on the PC, and retrieves other data as applications request it. This paper examines the cost of those downloads for MirageSSD's encrypted cloud representation. In a controlled test of its implemented reader, a 2,184-byte verification catalog allowed a later sparse read to fetch 65,536 bytes after an initial 4,194,372-byte download. The roughly 64-fold difference concerns transferred content for an eligible later miss; initial access still requires the full frame. The result motivates a broader research question: under a fixed memory budget, how should a cache divide space between file contents and verification metadata? This paper presents the mechanism, its measured scope, a worked cost model, and an evaluation plan for the allocation problem.

A cloud drive still has to find the bytes

Opening a file through a familiar drive letter hides a fair amount of work. If the requested bytes live on the computer, the storage system can return them locally. Otherwise, the application waits while the system contacts a server, downloads data, and checks its contents.

MirageSSD is an open-source project for accessing cloud-backed files through an ordinary Windows drive letter. It keeps selected data on the PC and stores encrypted cloud copies in Google Drive. When an application writes a file to its managed drive, the data first reaches local storage. A background process encrypts it, uploads it, and verifies the remote copy before the local data becomes eligible for eviction.

Eviction means removing a recoverable local copy to make room, with the cloud copy available for a later download. MirageSSD is currently an engineering preview. This paper studies its Windows managed-storage reader. Project overview.

The cache holds local copies for reuse. More cache space can save downloads, though the user pays for it in occupied storage. Inside the running program, additional caches use RAM to hold decoded data and verification information. Disk space and RAM have separate budgets and different jobs.

Consider a possible customer: a software company building a desktop viewer for large engineering datasets. A user might inspect a few details, switch projects, and return later. Downloading entire datasets gives the application local access after the transfer. Fetching pieces on demand spreads the waiting through the session. A local cache helps, until a large enough workload pushes earlier data out.

For MirageSSD, the size of an encrypted unit made this tradeoff particularly awkward. Its existing format groups file contents into frames of up to 4 MiB, roughly four megabytes. A small application read could therefore trigger a full-frame download for verification. A 4 KiB request, about four kilobytes, could bring back about a thousand times as much content.

Keeping the frame solved the next access at the price of four megabytes of residency. The experiment began with a more specific question: after releasing those bytes, could the reader retain enough information to make a later download smaller?

Keeping a useful trace of the frame

Encryption turns original file contents, or plaintext, into ciphertext. Authentication lets the reader check the recovered contents before handing them to an application. MirageSSD's ordinary full-frame path performs an authenticated decryption and checks the result against a trusted BLAKE3 hash, a compact fingerprint of the original plaintext. The trusted frame length accompanies this hash.

BLAKE3 organizes its computation as a tree, with a final fingerprint, the root, at the top. Retaining selected intermediate values lets the reader check a small region against this root after fetching just the relevant ciphertext.

The implementation learns this information during the first complete, verified read. It divides the plaintext into 64 KiB sectors and builds a catalog of tree values, along with the frame header and identity information. This initial download and catalog creation form the bootstrap step. For the 4 MiB fixture, the catalog occupies 2,184 bytes under the implementation's allocation accounting, about 0.052% of the original plaintext frame. Implementation and allocation accounting.

Those bytes hold verification information. Recovering file contents still requires either a local data copy or a download. Their value appears during a later access: the reader can fetch a covering ciphertext sector, decrypt it, and connect its contents back to the trusted fingerprint through the catalog.

This gives the cache three useful retention choices:

Local retention	How a later request is served
Data and catalog	Resident data serves a covered request locally; the catalog supports other sectors.
Catalog alone	The reader downloads covering sectors and verifies them against the original root.
Both entries evicted	The reader downloads and verifies the full frame again, rebuilding the catalog.

For a frequently used sector, retaining its contents is valuable. During occasional access to scattered regions of a large frame, the much smaller catalog could earn its space across several different reads. A rarely revisited frame may deserve eviction from both caches. Choosing between these cases is the proposed policy research; the present implementation uses separate byte-bounded caches with least-recently-used eviction.

MirageSSD can apply this mechanism to its existing encrypted objects. A complete verified read builds the catalog, and the cloud objects stay in their original format. This could matter during an upgrade of a large stored collection, since a format migration would introduce its own download, rewrite, and upload work.

The cryptographic boundary deserves precision. The first read checks the complete frame's original authentication tag and plaintext root. A later sector read authenticates the requested plaintext against the same trusted root. Checking the original whole-frame tag and the rest of the ciphertext requires a complete-frame operation. The reader releases selected bytes only after verification succeeds; corrupted inputs produce integrity errors. Reader contract.

At the cipher level, XChaCha20 supports seeking to the required position. MirageSSD uses a keystream offset of 64 plus the plaintext offset, reserving the first cipher block for the existing authentication construction. Correct tree positions, frame lengths, and object identities are equally important. The design relies on the original trusted publication metadata and established cryptographic assumptions. Independent cryptographic review remains part of further qualification.

What the implemented reader actually did

The October 13 integration test used the real managed reader and a counting backend over disposable local objects. A synthetic 4 MiB file passed through the actual publication and encryption path. The fixture also placed the encrypted payload behind an 8,192-byte prefix inside a provider object, exercising packed-object addressing.

For this test, whole-frame residency was set to zero. Sector residency had a 128 KiB budget, and the catalog budget was 4 KiB. These settings deliberately exercised reads after the full-frame data had gone. The backend added a fixed 30-millisecond delay; the reported result concerns byte and request counts from this controlled fixture.

Operation	Transferred content	Backend requests
Initial 4 KiB application read, before catalog creation	4,194,372 bytes	4
Later 4 KiB read in another 64 KiB sector	65,536 bytes	1
Sixteen concurrent readers requesting a further sector	65,536 bytes in total	1 shared request

The initial transfer includes the 4 MiB frame and its 68-byte envelope. The catalog supplies the header and verification information for the later read. These counts describe transferred object content at the backend interface; protocol overhead belongs in a separate network measurement. After the shared read, the fixture retained 131,072 bytes of sector data and the 2,184-byte catalog. Every returned range was compared with the original bytes. Test source and recorded results.

The concurrency result matters for a practical reason. Several application threads can ask for overlapping data at nearly the same moment. Sharing the work keeps a single useful download from turning into sixteen copies of the same transfer. Broader integration coverage also exercises the eight-owner limit on simultaneous misses, cross-frame reads, damaged inputs, retries, and dense-read behavior. Integration report.

Application response time needs a further measurement. A smaller download can reduce transfer and processing work, while server delay, network round trips, contention, and the application's own work continue to affect the wait. The measured 64-fold ratio describes one eligible later miss. End-to-end latency, game frame rates, and long-term disk use each require their own experiments.

The first download belongs in the bill

A user experiences an entire session, including its expensive first access. Including this initial cost makes a session-level calculation more useful for buying decisions than the later-miss ratio alone.

Take a deliberately simple example. A frame is accessed once, then revisited after its data has been evicted. Each revisit requires one 64 KiB sector. The catalog survives for the whole sequence. The full-frame alternative refetches the entire frame on each revisit. Both alternatives start with the same bootstrap download.

Let F = 4,194,372 bytes, S = 65,536 bytes, and r be the number of revisits. Total transfer is (1 + r) × F for full-frame refetching and F + r × S for catalog-assisted reads.

Access sequence	Full-frame refetching	Catalog-assisted reads	Ratio of total transferred content
Initial access	4,194,372 bytes	4,194,372 bytes	1.00
Initial access and one revisit	8,388,744 bytes	4,259,908 bytes	1.97
Initial access and ten revisits	46,138,092 bytes	4,849,732 bytes	9.51

These are calculated examples under the stated eviction pattern. They help expose the economics of catalog retention. Repeated sparse access makes the initial download easier to amortize. A one-pass workload gets its value from the first transfer and moves on.

Catalog lifetime matters just as much. MirageSSD currently keeps catalogs in memory. A remount or catalog eviction requires another bootstrap. Persistent catalogs could carry the benefit across sessions, provided recovery preserves the connection between the proof, the exact stored representation, and the trusted publication metadata. Persistence remains proposed work.

The whole-frame alternative in this example also deserves a fair trial. With enough space, it could retain a useful frame and serve many later requests locally. A workload benchmark must let each policy use the same total memory budget, including its metadata. Forced eviction establishes the mechanism; equal-budget replay would establish its practical advantage.

The research question extends beyond MirageSSD

Verified partial reads already have a substantial foundation. Bao supports BLAKE3 verified streaming and random access, and its outboard format keeps verification information separate from file contents. MirageSSD's implementation applies established tree-verification ideas to its existing encrypted representation and learns the catalog during an authenticated full read. Bao documentation and format specification.

Cache research also offers a richer starting point than recency alone. GreedyDual-Size incorporates retrieval cost and object size into replacement decisions. RobinHood reallocates cache resources according to their effect on slow application requests. These approaches make the value of saved time and saved transfer part of the allocation problem. GreedyDual-Size; RobinHood.

A cache policy has to price two kinds of usefulness here: serving a request from resident data, and reducing the cost of a future download through verification metadata. These values move together as access patterns, network conditions, and available memory change.

Two policies can have identical data hit rates and very different download bills. A catalog-assisted read still counts as a data miss, even as verification metadata cuts its transfer. Using hit rate as the sole evaluation metric could undervalue the catalog.

For a rough decision model, estimate the number of future sparse revisits during a catalog's lifetime. Multiply it by the expected cost difference between full-frame recovery and sector recovery, then account for catalog construction and verification work. Compare the remaining benefit with the value of giving the same memory to data. Retrieval cost can be measured in waiting time, transferred bytes, or provider charges, depending on the product's constraints.

The difficult part is estimating future demand. An application might revisit one tiny region hundreds of times, browse many sectors once, or alternate between a scan and scattered reads. A policy could spend too much memory remembering a large collection of frames after the user has moved to another project. The 2,184-byte catalog makes this a promising question; its small size still has to earn a place in the budget.

The broader research proposal is to allocate memory jointly between data and verification metadata for existing encrypted representations, then test the result against strong alternatives. Establishing novelty calls for a deeper literature review alongside the experiments below. Today's concrete contribution consists of the implemented reader and its controlled integration evidence.

An experiment capable of changing the recommendation

The next evaluation should use recorded access traces from consenting desktop application users; synthetic traces could then isolate specific edge cases. Separate training and evaluation sessions would test adaptation across project switches and changes in behavior. Useful workloads include repeated inspection of a small region, scattered revisits across large files, sequential scans, and full integrity checks.

An equal-budget full-frame cache should compete with both fixed and adaptive allocations across frame, sector, and catalog caches. A cost-aware replacement policy would help test whether retrieval-cost estimates already explain the gain. If the team controls its storage format, independently authenticated small chunks provide another important competitor. Publisher-generated verification metadata also deserves comparison, since it offers a route to small first reads.

Every implementation should preserve the same required content-authenticity contract. Format-changing alternatives should report migration work separately, giving both ongoing operating cost and transition cost. Each run should count catalog construction, bootstrap downloads, prefetching, retries, active fetch buffers, and retained metadata. RAM and persistent disk require separate accounting; process memory adds allocator and runtime overhead to cache contents.

The primary comparison would plot application waiting time against total retained memory, with transferred bytes alongside it. Median and 99th-percentile read latency, startup delay, CPU time, and provider request counts would show different parts of the tradeoff. Repeated runs with alternating order and uncertainty intervals would help distinguish stable gains from timing noise. Experiments should also include restarts, catalog churn, high round-trip delay, bandwidth limits, and corruption cases.

Two smaller experiments can explain any overall result. First, hold sector size constant and vary the catalog budget to find its useful range. Then hold total memory constant and vary the split between data and catalogs. Use separate tuning traces to choose the strongest fixed split, then compare it with the adaptive policy during evaluation. A gain against a poorly sized baseline would say little about the policy itself.

The hypothesis predicts a useful middle region: the workload revisits encrypted frames, the data working set exceeds the available cache, and a compact catalog working set still fits. During long sequential reads, larger transfers should remain attractive, while repeated access to a tiny region should reward data retention. Frequent catalog loss should pull results toward the full-frame baseline.

Success would mean a better tradeoff across held-out workloads at equal budgets, together with clear conditions for choosing another approach. A result favoring a simpler fixed partition would also be useful: it would turn a speculative policy problem into a cheaper implementation decision.

Choosing a storage product for an actual application

For the engineering-data viewer, the first conversation should concern the user's work. A trace can show how much data a session touches and how often the user returns to an earlier region. Customer interviews can put an acceptable storage footprint and waiting time around those observations. Together, this evidence would shape the storage choice more reliably than a single transfer ratio.

Approach	Strong reason to choose it	Cost to evaluate
Complete local download	The user needs an entire dataset locally or expects to work offline.	Initial transfer time, update traffic, and disk capacity.
Conventional data cache	A useful working set fits locally and repeat accesses cluster within it.	Misses after eviction and the footprint of retained data.
Independently authenticated small chunks	The team controls the stored format and wants small reads from first access.	Chunk metadata, request overhead, publication changes, and migration.
Learned verification catalogs	Existing supported encrypted frames receive sparse revisits after data eviction.	Initial bootstrap, catalog lifetime, verification CPU, and network availability.

A possible commercial product would package the reader as a storage SDK with a local service and a diagnostic view. The SDK would provide supported verified reads; the service would enforce storage budgets; diagnostics would connect a slow operation to its download, verification, and cache behavior. Customers would be buying predictable resource use and a shorter integration project. Those benefits need a customer pilot and measured application outcomes.

The first pilot could use one dataset format and one desktop workflow. Record the present application's transfer volume, local footprint, and waiting time. Run the catalog-assisted reader against the same access sequence and budget, including the first download and a restart. An engineering lead could then compare observed savings with implementation effort and ongoing support cost.

MirageSSD provides a concrete starting point for such a pilot. Its current product remains a preview with machine-bound keys and plaintext local caches. A reusable SDK, persistent catalogs, and commercial support remain future product work. For a buyer, those details affect deployment and ownership of the system alongside the performance figures. Current product scope.

The pilot starts with a working mechanism: MirageSSD's existing encrypted format supported a later verified read through a 65,536-byte transfer, with a 2,184-byte catalog in memory. A customer workload would put a practical value on the remaining question: how long does this small piece of retained knowledge stay useful, and what else could occupy its space?

Reproduction and evidence

The implementation is available in MirageSSD v0.1.20-preview, at source revision 78076b507c793ff71bf60b4a0f86829b6abc5afe. The measurements in this paper come from the October 13 integration record. This draft analyzes those existing results and adds the explicitly calculated session example.

After following the repository's build prerequisites, the focused fixture and sector checks can be run with:

cargo test -p mirage-ffi --test cold_read --locked learned_proofs_make_later_sparse_misses_small_and_shared -- --nocapture
cargo test -p mirage-pack --locked verified_sector -- --nocapture

The broader cold-read suite exercises the additional integration cases from the evaluation section:

cargo test -p mirage-ffi --test cold_read --locked -- --nocapture

The primary materials are the sector-verification implementation, reader contract, integration fixture, and machine-readable record. The October 12 fine-grained seek prototype is a separate experiment; the integrated reader evaluated here uses 64 KiB sectors.