-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new DataCache trait and InMemoryDataCache implementation #557
Conversation
Signed-off-by: Daniel Carl Jones <djonesoa@amazon.com>
There will be a small conflict with #556. I'll rebase this once that's merged. |
mountpoint-s3/src/data_cache/mod.rs
Outdated
/// Get block of data from the cache for the given [Key] and [BlockIndex], if available. | ||
/// | ||
/// Operation may fail due to errors, or return [None] if the block was not available in the cache. | ||
fn get_block(&self, cache_key: &Key, block_idx: BlockIndex) -> DataCacheResult<Option<&ChecksummedBytes>>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two thoughts here:
- Does the client decide how block indexing works (and the implementation treats them as opaque), or do the implementation and client need to agree on how that works somehow?
- If it's the former, can they just be part of the generic
Key
type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the client decide how block indexing works (and the implementation treats them as opaque), or do the implementation and client need to agree on how that works somehow?
I hadn't fully thought this through yet. I think for now we will move towards the implementation knowing about "blocks" and surfacing things like the cache's block size in the trait. Client will need to use that information to calculate things such as:
- If I want to fetch some data, what ranges should I use for full blocks?
- If I read from blocks, what do I need to trim at the start and end?
I'm hoping we can move that logic into the DataCache trait later, but for now I'm not sure exactly how it'll look like.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good first stab at the trait. Left a few comments.
… to caller Signed-off-by: Daniel Carl Jones <djonesoa@amazon.com>
…rt_eq_checksummed_bytes macro Signed-off-by: Daniel Carl Jones <djonesoa@amazon.com>
Signed-off-by: Daniel Carl Jones <djonesoa@amazon.com>
Signed-off-by: Daniel Carl Jones <djonesoa@amazon.com>
Signed-off-by: Daniel Carl Jones <djonesoa@amazon.com>
Signed-off-by: Daniel Carl Jones <djonesoa@amazon.com>
Signed-off-by: Daniel Carl Jones <djonesoa@amazon.com>
Description of change
Part of #255, this contains some early thinking on what our trait should look like for the data cache itself. It also contains an in-memory implementation that can be used for test cases, without setting up a full data cache (which doesn't exist yet).
Relevant issues: #255
Does this change impact existing behavior?
No.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and I agree to the terms of the Developer Certificate of Origin (DCO).