pub struct FileSpaceInfoMessage {
pub version: u8,
pub strategy: FileSpaceStrategy,
pub persist: bool,
pub threshold: u64,
pub page_size: u64,
pub pgend_meta_thres: u16,
pub eoa_pre_fsm_fsalloc: u64,
pub fs_addr: Vec<u64>,
}Expand description
File-space info message (0x0017) — H5Ofsinfo.c.
The version-0 form is the deprecated 1.10.0 encoding. Its four strategy
values are mapped onto the version-1 strategy/persist/threshold
fields on decode (H5O__fsinfo_decode), so every consumer of this struct
sees one shape whatever the file carries.
What decode does not discard is which encoding the file used:
version keeps it and encode re-emits
at that version, so appending to a version-0 file leaves it a version-0
file. Upstream instead upgrades — H5O__fsinfo_encode has no version-0
branch, and H5F__super_read removes a mapped message and writes a
version-1 replacement on read-write open (H5Fsuper.c:843-885) — which is a
format change this crate has no reason to make on the user’s behalf, and
which libhdf5 will still make on its own next open.
Fields§
§version: u8The encoding this message uses on disk: 0 for the deprecated 1.10.0 form, 1 for the current one. Decode records what it read and encode writes that same form back; nothing else in the crate branches on it, because decode has already normalized the fields below.
strategy: FileSpaceStrategyFile-space handling strategy.
persist: boolWhether free-space manager state is persisted across close/reopen.
threshold: u64Smallest free-space section tracked by a manager.
page_size: u64File-space page size (paged aggregation).
pgend_meta_thres: u16Page-end metadata threshold.
eoa_pre_fsm_fsalloc: u64End-of-address before free-space header/section allocation.
fs_addr: Vec<u64>Addresses of the free-space managers, indexed by
FreeSpaceManager::message_slot.
Always FS_ADDR_COUNT_V1 entries, undefined where there is no
manager — including for a non-persisting message, which stores none of
them, and for a version-0 message, which stores only the first
FS_ADDR_COUNT_V0. Upstream keeps the same full-width array for the
same reason (H5O__fsinfo_decode fills all twelve with HADDR_UNDEF
before reading any): a caller indexes a slot without first asking which
encoding the slot came from.
Implementations§
Source§impl FileSpaceInfoMessage
impl FileSpaceInfoMessage
Sourcepub fn decode(buf: &[u8], ctx: &FormatContext) -> FormatResult<Self>
pub fn decode(buf: &[u8], ctx: &FormatContext) -> FormatResult<Self>
Decode the message body.
Sourcepub fn encode(&self, ctx: &FormatContext) -> FormatResult<Vec<u8>>
pub fn encode(&self, ctx: &FormatContext) -> FormatResult<Vec<u8>>
Encode the message body at the version it was decoded at
(H5O__fsinfo_encode, plus the version-0 layout upstream only reads).
Fails only for a version-0 message carrying something that encoding
cannot express, which decode cannot produce and only a caller that
edited the message can reach — see encode_v0.
Sourcepub fn encode_v0(&self, ctx: &FormatContext) -> FormatResult<Vec<u8>>
pub fn encode_v0(&self, ctx: &FormatContext) -> FormatResult<Vec<u8>>
Encode the deprecated 1.10.0 body, the inverse of what
H5O__fsinfo_decode’s version-0 branch reads.
Upstream has no such encoder: it decodes version 0, marks the message
mapped, and rewrites it as version 1 on the next read-write open
(H5Fsuper.c:866-880). This crate re-emits instead, so appending to a
version-0 file does not silently change its on-disk format — but that
is only sound while every field still fits, so the ones the encoding
cannot hold are checked rather than assumed:
strategy/persistmust be one of the fourH5F_file_space_type_tcombinations; paged aggregation postdates this encoding.thresholdis stored only for the twoFSM_AGGRvalues; the other two are decoded as 1 and must still be 1.- the managers past the sixth must be undefined, there being no slot for them.
page_size, pgend_meta_thres and eoa_pre_fsm_fsalloc are not
checked, because the version-0 encoding never carried them: decode
synthesizes all three, and the next decode synthesizes them again from
the same rule. Writing back the first two would be writing back
constants; the third is re-derived from the file’s end of allocation,
which is the value it would have anyway.