The maxEntries=500 here is specific to SingleFileStore and removes entries without notifications as this is outside of the normal scope of eviction. If you want you can create an improvement JIRA to add some sort of notification specifically for SingleFileStore (although I am not quite sure what that would look like). Another option is you can use the new soft-index file store  which can be acquired at  (this doesn't have the issue of storing every key in memory.
Thanks for the clarification, William. The responsible method in SingleFileStore is named evict(), that's why I assumed it's also an eviction.
Restrictions to key length in the soft-index file store made me discard it as an alternative, although they could probably be worked around. Besides the term "experimental" in the docs makes me wonder how stable the implementation is. We're gonna consider both options.
Soft-index File Store is pretty complicated chunk of code, and unless we see successful adoption in community, it will be tagged as experimental. That's how the community works, there are not enough resources to thoroughly test everything, but users participation may help.
May I ask about your usecase, what kind of keys are you storing? With the usecases I have in mind, keys are short IDs, or names, UUIDs, serial numbers... Why do you need keys > 32kB?
I misread the part about key size in the docs when skimming over it. Thought it would be limited to 15 bytes. May I suggest to replace the minus symbol with "minus" as a word?
> you can’t use keys longer than size of the node - 15 bytes.
Our keys are 64 byte uuids. The values are usually very small (< 1K), but in some cases which we expect to be rare, they can also be 300K or 500K, will that cause problems with managing the data files? Will the soft-index file store always reserve space for the max node size?
The size of value is limited to 2GB (signed integer), values are not a part of the index, they can be even stored on different disk. I wouldn't expect any trouble with such values.
Btw., one more thing you may have misinterpreted: SingleFileStore.maxEntries is not obligatory (by default it's unlimited), if all your keys can fit into memory, you don't have to care about disk eviction.
Our usage scenario is a little special. The values contain a reference to very large files managed by an external system. We need to trigger a clean up of this data when we lose the reference to limit disk space usage.