ChunkCache drops a dirty chunk if saving it during eviction fails
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
- Domain
- data-engineering
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
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from cryptomator/cryptofs
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
cryptomator/cryptofs#246 · 6 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
cryptomator/cryptofs#177 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
cryptomator/cryptofs#171 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
cryptomator/cryptofs#153 ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
cryptomator/cryptofs#151 ·
All issues in cryptomator/cryptofs
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
wultra/powerauth-tests#980 ·
-
account bug communication lecture
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
line/centraldogma#1397 ·
Maintainers usually reply within 2 days
-
[Bug]: Fixed/recurring deposit accounts are treated as savings in ownership and listingsPossibly taken @Aana123 claimed this today. Openbug Triage
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
apache/fineract-consumer-facing#252 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
cryptomator/hub#515 ·