ChunkCache drops a dirty chunk if saving it during eviction fails

Open
#372 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
cloud, java

Research direction

Start with ChunkCache and the eviction listener wired through Caffeine's .executor(Runnable::run), plus the chunkSaver.save call that catches IOException and NonWritableChannelException. The issue suggests a side map drained by flush() or excluding dirty chunks from eviction, but the design choice is open. Done means a dirty chunk survives a failed save during eviction and is written or reported by force(), which needs fault-injected tests since reproduction is unclear.

Written by the indexing model from the issue text.

Description

I was reading ChunkCache while working on #370 and noticed this:

try {
    chunkSaver.save(index, chunk);
} catch (IOException | NonWritableChannelException e) {
    exceptionsDuringWrite.add(e);
}
bufferPool.recycle(chunk.data());

By the time this runs the chunk is already out of the cache, so if the save fails there is nothing left to retry. The exception is recorded and surfaces later in force(), but the data is gone, and the write() that produced it had already returned, so from the caller's side it looks written.

The cache holds at most five idle chunks (MAX_CACHED_CLEARTEXT_CHUNKS), so writing a file with more chunks evicts dirty ones as a matter of course. A transient ENOSPC or EIO at the wrong moment is enough.

I have not tried to reproduce it. It needs the save to fail exactly during eviction, so I guess it takes fault injection rather than a real filesystem.

It also does not look like a one-liner: the listener runs inside Caffeine's eviction (.executor(Runnable::run)), so re-inserting from there would just evict again. Keeping failed chunks in a side map drained by flush(), or keeping dirty chunks out of eviction altogether, both seem plausible.

Happy to take this if you think it is worth fixing.

Dominant language
Java
Stars
110
Forks
39
Avg merge
1d 28m
Merged PRs (30d)
4

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cryptomator/cryptofs

All issues in cryptomator/cryptofs

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.