Skip to content

feat: expose fd cache - #181

Open
selmanozleyen wants to merge 1 commit into
zarrs:mainfrom
selmanozleyen:feat/expose-fd-cache
Open

feat: expose fd cache#181
selmanozleyen wants to merge 1 commit into
zarrs:mainfrom
selmanozleyen:feat/expose-fd-cache

Conversation

@selmanozleyen

@selmanozleyen selmanozleyen commented Aug 2, 2026

Copy link
Copy Markdown

Hi!

This file handler caching saves my life on some other performance optimization paths I am working on. So I think it makes sense that this is finally exposed.

  • zarrs_filesystem has FilesystemStoreOptions::file_handle_cache_size since 0.3.11 (zarrs#422), but it is unreachable from Python: FilesystemStoreConfig::opts is private and only options with an explicit forwarding method can be set.

  • The README notes the one zarr-python-specific caveat: the upstream option does not observe external modification.

  • One question — the code uses an API added in zarrs_filesystem 0.3.11, but the manifest is unchanged, since zarrs requires ^0.3.9 and resolution picks 0.3.12. That means -Z minimal-versions fails. Happy to add zarrs_filesystem = "0.3.11" as a direct dependency if you would rather it were declared.

zarrs_filesystem has had FilesystemStoreOptions::file_handle_cache_size
since 0.3.11 (zarrs#422), but zarrs-python never forwarded it, so Python
users cannot reach it: FilesystemStoreConfig::opts is private and only
options with an explicit forwarding method are settable.

Forward it as direct_io is already forwarded -- config key ->
CodecPipelineImpl::new -> StoreConfig -> FilesystemStoreConfig -> opts,
with the StoreConfig match no-opping for the HTTP and ObStore variants.
Defaults to 0, the same default zarrs_filesystem applies.

The upstream option is documented as invalidating on writes and erases
through its own store, but not on external modification. The README notes
what that means here specifically: zarr-python is itself such an external
writer, because resize, delete_dir and metadata writes go through its own
store rather than this pipeline's, so a cached handle can outlive the chunk
file it refers to. The Zarr specification does not define behaviour for
concurrent modification, so this is a property of the option rather than a
defect; it is off by default.

The test asserts the cache is actually engaged rather than only that reads
are correct: reading a sharded array holds exactly file_handle_cache_size
descriptors open, and none when disabled.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant