pub struct ChunkKey {
pub chunk_size: u32,
pub filter_mask: u32,
pub offsets: Vec<u64>,
}Expand description
A decoded chunk key from a raw-data-chunk (type-1) B-tree v1 node.
Fields§
§chunk_size: u32Size in bytes of the stored chunk (compressed size when filtered).
filter_mask: u32Filter mask: bit i set means filter i was skipped for this chunk.
offsets: Vec<u64>Per-dimension element offsets of the chunk’s first element. The
trailing entry is the element-size dimension and is always 0, so
this has rank + 1 entries.
Implementations§
Source§impl ChunkKey
impl ChunkKey
Sourcepub fn for_chunk(
scaled: &[u64],
dims: &[u64],
chunk_size: u32,
filter_mask: u32,
) -> Self
pub fn for_chunk( scaled: &[u64], dims: &[u64], chunk_size: u32, filter_mask: u32, ) -> Self
The key describing the stored chunk whose grid position is scaled.
dims is the layout message’s chunk shape — rank + 1 entries, the
last being the element size — because the key stores element offsets,
scaled[u] * dims[u] (H5D__btree_encode_key, H5Dbtree.c). A stored
chunk begins at element 0 of its own footprint, so the element
dimension of scaled is 0 and this appends it rather than asking the
caller for it.
Sourcepub fn right_bound(scaled: &[u64], dims: &[u64]) -> Self
pub fn right_bound(scaled: &[u64], dims: &[u64]) -> Self
The right-boundary key closing a tree whose greatest chunk sits at
scaled: a zero-width chunk one element-size past it.
A v1 B-tree stores both bounds of every child, and a search descends
only where lt_key <= target < rt_key under the lexicographic order
of H5VM_vector_cmp_u (H5VMprivate.h). Moving the element dimension —
the least significant one, and 0 for every stored chunk — on by one is
what makes the greatest chunk fall inside its own node instead of past
its right bound; libhdf5 reaches the same key from the other side, by
setting scaled + 1 when it opens a node (H5D__btree_new_node) and
leaving it alone for every insert that lands within the bound.