HDF5 File Format Specification Version 3.0

Format Signature

This field contains a constant value and can be used to quickly identify a file as being an HDF5 file. The constant value is designed to allow easy identification of an HDF5 file and to allow certain types of data corruption to be detected. The file signature of an HDF5 file always contains the following values:

This signature both identifies the file as an HDF5 file and provides for immediate detection of common file-transfer problems. The first two bytes distinguish HDF5 files on systems that expect the first two bytes to identify the file type uniquely. The first byte is chosen as a non-ASCII value to reduce the probability that a text file may be misrecognized as an HDF5 file; also, it catches bad file transfers that clear bit 7. Bytes two through four name the format. The CR-LF sequence catches bad file transfers that alter newline sequences. The control-Z character stops file display under MS-DOS. The final line feed checks for the inverse of the CR-LF translation problem. (This is a direct descendent of the PNG file signature.)

This field is present in version 0+ of the superblock.

Version Number of the Superblock

This value is used to determine the format of the information in the superblock. When the format of the information in the superblock is changed, the version number is incremented to the next integer and can be used to determine how the information in the superblock is formatted.

Values of 0, 1 and 2 are defined for this field (the format of version 2 is described below, not here).

This field is present in version 0+ of the superblock.

Version Number of the File’s Free Space Information

This value is used to determine the format of the file’s free space information.

The only value currently valid in this field is ‘0’, which indicates that the file’s free space is as described below.

This field is present in versions 0 and 1 of the superblock.

Version Number of the Root Group Symbol Table Entry

This value is used to determine the format of the information in the Root Group Symbol Table Entry. When the format of the information in that field is changed, the version number is incremented to the next integer and can be used to determine how the information in the field is formatted.

The only value currently valid in this field is ‘0’, which indicates that the root group symbol table entry is formatted as described below.

This field is present in version 0 and 1 of the superblock.

Version Number of the Shared Header Message Format

This value is used to determine the format of the information in a shared object header message. Since the format of the shared header messages differs from the other private header messages, a version number is used to identify changes in the format.

The only value currently valid in this field is ‘0’, which indicates that shared header messages are formatted as described below.

This field is present in version 0 and 1 of the superblock.

Size of Offsets

This value contains the number of bytes used to store addresses in the file. The values for the addresses of objects in the file are offsets relative to a base address, usually the address of the superblock signature. This allows a wrapper to be added after the file is created without invalidating the internal offset locations.

This field is present in version 0+ of the superblock.

Size of Lengths

This value contains the number of bytes used to store the size of an object.

This field is present in version 0+ of the superblock.

Group Leaf Node K

Each leaf node of a group B-tree will have at least this many entries but not more than twice this many. If a group has a single leaf node then it may have fewer entries.

This value must be greater than zero.

See the description of B-trees below.

This field is present in version 0 and 1 of the superblock.

Group Internal Node K

Each internal node of a group B-tree will have at least this many entries but not more than twice this many. If the group has only one internal node then it might have fewer entries.

This value must be greater than zero.

See the description of B-trees below.

This field is present in version 0 and 1 of the superblock.

File Consistency Flags

This field is unused and should be ignored.

This field is present in version 0+ of the superblock.

Indexed Storage Internal Node K

Each internal node of an indexed storage B-tree will have at least this many entries but not more than twice this many. If the index storage B-tree has only one internal node then it might have fewer entries.

This value must be greater than zero.

See the description of B-trees below.

This field is present in version 1 of the superblock.

Base Address

This is the absolute file address of the first byte of the HDF5 data within the file. The library currently constrains this value to be the absolute file address of the superblock itself when creating new files; future versions of the library may provide greater flexibility. When opening an existing file and this address does not match the offset of the superblock, the library assumes that the entire contents of the HDF5 file have been adjusted in the file and adjusts the base address and end of file address to reflect their new positions in the file. Unless otherwise noted, all other file addresses are relative to this base address.

This field is present in version 0+ of the superblock.

Address of Global Free-space Index

The file’s free space is not persistent for version 0 and 1 of the superblock. Currently this field always contains the undefined address.

This field is present in version 0 and 1 of the superblock.

End of File Address

This is the absolute file address of the first byte past the end of all HDF5 data. It is used to determine whether a file has been accidently truncated and as an address where file data allocation can occur if space from the free list is not used.

This field is present in version 0+ of the superblock.

Driver Information Block Address

This is the relative file address of the file driver information block which contains driver-specific information needed to reopen the file. If there is no driver information block then this entry should be the undefined address.

This field is present in version 0 and 1 of the superblock.

Root Group Symbol Table Entry

This is the symbol table entry of the root group, which serves as the entry point into the group graph for the file.

This field is present in version 0 and 1 of the superblock.

Format Signature

This field is the same as described for versions 0 and 1 of the superblock.

Version Number of the Superblock

This field has a value of 2 and has the same meaning as for versions 0 and 1.

Size of Offsets

This field is the same as described for versions 0 and 1 of the superblock.

Size of Lengths

This field is the same as described for versions 0 and 1 of the superblock.

File Consistency Flags

For superblock version 2: This field is unused and should be ignored.

For superblock version 3: This value contains flags to ensure file consistency for file locking. Currently, the following bit flags are defined:

• Bit 0 if set indicates that the file has been opened for write access.
• Bit 1 is reserved for future use.
• Bit 2 if set indicates that the file has been opened for single-writer/multiple-reader (SWMR) write access.
• Bits 3-7 are reserved for future use.

Bit 0 should be set as the first action when a file has been opened for write access. Bit 2 should be set when a file has been opened for SWMR write access. These two bits should be cleared only as the final action when closing a file.

This field is present in version 0+ of the superblock.

The size of this field has been reduced from 4 bytes in superblock format versions 0 and 1 to 1 byte.

Base Address

This field is the same as described for versions 0 and 1 of the superblock.

Superblock Extension Address

The field is the address of the object header for the superblock extension. If there is no extension then this entry should be the undefined address.

End of File Address

This field is the same as described for versions 0 and 1 of the superblock.

Root Group Object Header Address

This is the address of the root group object header, which serves as the entry point into the group graph for the file.

Superblock Checksum

The checksum for the superblock.

Version

The version number of the Driver Information Block. This document describes version 0.

Driver Information Size

The size in bytes of the Driver Information field.

Driver Identification

This is an eight-byte ASCII string without null termination which identifies the driver and/or version number of the Driver Information Block. The predefined driver encoded in this field by the HDF5 Library is identified by the letters NCSA followed by the first four characters of the driver name. If the Driver Information block is not the original version then the last letter(s) of the identification will be replaced by a version number in ASCII, starting with 0.

Identification for user-defined drivers is also eight-byte long. It can be arbitrary but should be unique to avoid the four character prefix “NCSA”.

Driver Information

Member Mapping

These fields are integer values from 1 to 6 indicating how the data can be mapped to or merged with another type of data.

Member Mapping	Description
1	The superblock data.
2	The B-tree data.
3	The raw data.
4	The global heap data.
5	The local heap data.
6	The object header data.

For example, if the third field has the value 3 and all the rest have the value 1, it means there are two files: one for raw data, and one for superblock, B-tree, global heap, local heap, and object header.

Reserved

These fields are reserved and should always be zero.

Address of Member File N

This field Specifies the virtual address at which the member file starts.

N is the number of member files.

End of Address for Member File N

This field is the end of the allocated address for the member file.

Name of Member File N

This field is the null-terminated name of the member file and its length should be multiples of 8 bytes. Additional bytes will be padded with NULLs. The default naming convention is %s-X.h5, where X is one of the letters s (for superblock), b (for B-tree), r (for raw data), g (for global heap), l (for local heap), and o (for object header). The name of the whole HDF5 file will substitute the %s in the string.

Size of Member File

This field is the size of the member file in the family of files.

Signature

The ASCII character string “TREE” is used to indicate the beginning of a B-tree node. This gives file consistency checking utilities a better chance of reconstructing a damaged file.

Node Type

Each B-tree points to a particular type of data. This field indicates the type of data as well as implying the maximum degree K of the tree and the size of each Key field.

Node Type	Description
0	This tree points to group nodes.
1	This tree points to raw data chunk nodes.

Node Level

The node level indicates the level at which this node appears in the tree (leaf nodes are at level zero). Not only does the level indicate whether child pointers point to sub-trees or to data, but it can also be used to help file consistency checking utilities reconstruct damaged trees.

Entries Used

This determines the number of children to which this node points. All nodes of a particular type of tree have the same maximum degree, but most nodes will point to less than that number of children. The valid child pointers and keys appear at the beginning of the node and the unused pointers and keys appear at the end of the node. The unused pointers and keys have undefined values.

Address of Left Sibling

This is the relative file address of the left sibling of the current node. If the current node is the left-most node at this level then this field is the undefined address.

Address of Right Sibling

This is the relative file address of the right sibling of the current node. If the current node is the right-most node at this level then this field is the undefined address.

Keys and Child Pointers

Each tree has 2K+1 keys with 2K child pointers interleaved between the keys. The number of keys and child pointers actually containing valid values is determined by the node’s Entries Used field. If that field is N, then the B-tree contains N child pointers and N+1 keys.

Key

The format and size of the key values is determined by the type of data to which this tree points. The keys are ordered and are boundaries for the contents of the child pointer; that is, the key values represented by child N fall between Key N and Key N+1. Whether the interval is open or closed on each end is determined by the type of data to which the tree points.

The format of the key depends on the node type. For nodes of node type 0 (group nodes), the key is formatted as follows:

A single field of Size of Lengths bytes:

Indicates the byte offset into the local heap for the first object name in the subtree which that key describes.

For nodes of node type 1 (chunked raw data nodes), the key is formatted as follows:

Bytes 1-4:	Size of chunk in bytes.
Bytes 4-8:	Filter mask, a 32-bit bit field indicating which filters have been skipped for this chunk. Each filter has an index number in the pipeline (starting at 0, with the first filter to apply) and if that filter is skipped, the bit corresponding to its index is set.
(D + 1) 64-bit fields:	The offset of the chunk within the dataset where D is the number of dimensions of the dataset, and the last value is the offset within the dataset’s datatype and should always be zero. For example, if a chunk in a 3-dimensional dataset begins at the position [5,5,5], there will be three such 64-bit values, each with the value of 5, followed by a 0 value.

Child Pointer

The tree node contains file addresses of subtrees or data depending on the node level. Nodes at Level 0 point to data addresses, either raw data chunks or group nodes. Nodes at non-zero levels point to other nodes of the same B-tree.

For raw data chunk nodes, the child pointer is the address of a single raw data chunk. For group nodes, the child pointer points to a symbol table, which contains information for multiple symbol table entries.

Signature

The ASCII character string “BTHD” is used to indicate the header of a version 2 (v2) B-tree node.

Version

The version number for this B-tree header. This document describes version 0.

Type

This field indicates the type of B-tree:

Value	Description
0	This B-tree is used for testing only. This value should not be used for storing records in actual HDF5 files.
1	This B-tree is used for indexing indirectly accessed, non-filtered ‘huge’ fractal heap objects.
2	This B-tree is used for indexing indirectly accessed, filtered ‘huge’ fractal heap objects.
3	This B-tree is used for indexing directly accessed, non-filtered ‘huge’ fractal heap objects.
4	This B-tree is used for indexing directly accessed, filtered ‘huge’ fractal heap objects.
5	This B-tree is used for indexing the ‘name’ field for links in indexed groups.
6	This B-tree is used for indexing the ‘creation order’ field for links in indexed groups.
7	This B-tree is used for indexing shared object header messages.
8	This B-tree is used for indexing the ‘name’ field for indexed attributes.
9	This B-tree is used for indexing the ‘creation order’ field for indexed attributes.
10	This B-tree is used for indexing chunks of datasets with no filters and with more than one dimension of unlimited extent.
11	This B-tree is used for indexing chunks of datasets with filters and more than one dimension of unlimited extent.

The format of records for each type is described below.

Node Size

This is the size in bytes of all B-tree nodes.

Record Size

This field is the size in bytes of the B-tree record.

Depth

This is the depth of the B-tree.

Split Percent

The percent full that a node needs to increase above before it is split.

Merge Percent

The percent full that a node needs to be decrease below before it is split.

Root Node Address

This is the address of the root B-tree node. A B-tree with no records will have the undefined address in this field.

Number of Records in Root Node

This is the number of records in the root node.

Total Number of Records in B-tree

This is the total number of records in the entire B-tree.

Checksum

This is the checksum for the B-tree header.

Signature

The ASCII character string “BTIN” is used to indicate the internal node of a B-tree.

Version

The version number for this B-tree internal node. This document describes version 0.

Type

This field is the type of the B-tree node. It should always be the same as the B-tree type in the header.

Records

The size of this field is determined by the number of records for this node and the record size (from the header). The format of records depends on the type of B-tree.

Child Node Pointer

This field is the address of the child node pointed to by the internal node.

Number of Records in Child Node

This is the number of records in the child node pointed to by the corresponding Node Pointer.

The number of bytes used to store this field is determined by the maximum possible number of records able to be stored in the child node.

The maximum number of records in a child node is computed in the following way:

• Subtract the fixed size overhead for the child node (for example, its signature, version, checksum, and so on and one pointer triplet of information for the child node (because there is one more pointer triplet than records in each internal node)) from the size of nodes for the B-tree.
• Divide that result by the size of a record plus the pointer triplet of information stored to reach each child node from this node.

Note that leaf nodes do not encode any child pointer triplets, so the maximum number of records in a leaf node is just the node size minus the leaf node overhead, divided by the record size.

Also note that the first level of internal nodes above the leaf nodes do not encode the Total Number of Records in Child Node value in the child pointer triplets (since it is the same as the Number of Records in Child Node), so the maximum number of records in these nodes is computed with the equation above, but using (Child Pointer, Number of Records in Child Node) pairs instead of triplets.

The number of bytes used to encode this field is the least number of bytes required to encode the maximum number of records in a child node value for the child nodes below this level in the B-tree.

For example, if the maximum number of child records is 123, one byte will be used to encode these values in this node; if the maximum number of child records is 20000, two bytes will be used to encode these values in this node; and so on. The maximum number of bytes used to encode these values is 8 (in other words, an unsigned 64-bit integer).

Total Number of Records in Child Node

This is the total number of records for the node pointed to by the corresponding Node Pointer and all its children. This field exists only in nodes whose depth in the B-tree node is greater than 1 (in other words, the “twig” internal nodes, just above leaf nodes, do not store this field in their child node pointers).

The number of bytes used to store this field is determined by the maximum possible number of records able to be stored in the child node and its descendants.

The maximum possible number of records able to be stored in a child node and its descendants is computed iteratively, in the following way: The maximum number of records in a leaf node is computed, then that value is used to compute the maximum possible number of records in the first level of internal nodes above the leaf nodes. Multiplying these two values together determines the maximum possible number of records in child node pointers for the level of nodes two levels above leaf nodes. This process is continued up to any level in the B-tree.

The number of bytes used to encode this value is computed in the same way as for the Number of Records in Child Node field.

Checksum

This is the checksum for this node.

Signature

The ASCII character string “BTLF“ is used to indicate the leaf node of a version 2 (v2) B-tree.

Version

The version number for this B-tree leaf node. This document describes version 0.

Type

This field is the type of the B-tree node. It should always be the same as the B-tree type in the header.

Records

The size of this field is determined by the number of records for this node and the record size (from the header). The format of records depends on the type of B-tree.

Checksum

This is the checksum for this node.

Huge Object Address

The address of the huge object in the file.

Huge Object Length

The length of the huge object in the file.

Huge Object ID

The heap ID for the huge object.

Filtered Huge Object Address

The address of the filtered huge object in the file.

Filtered Huge Object Length

The length of the filtered huge object in the file.

Filter Mask

A 32-bit bit field indicating which filters have been skipped for this chunk. Each filter has an index number in the pipeline (starting at 0, with the first filter to apply) and if that filter is skipped, the bit corresponding to its index is set.

Filtered Huge Object Memory Size

The size of the de-filtered huge object in memory.

Huge Object ID

The heap ID for the huge object.

Huge Object Address

The address of the huge object in the file.

Huge Object Length

The length of the huge object in the file.

Filtered Huge Object Address

The address of the filtered huge object in the file.

Filtered Huge Object Length

The length of the filtered huge object in the file.

Filter Mask

A 32-bit bit field indicating which filters have been skipped for this chunk. Each filter has an index number in the pipeline (starting at 0, with the first filter to apply) and if that filter is skipped, the bit corresponding to its index is set.

Filtered Huge Object Memory Size

The size of the de-filtered huge object in memory.

Hash

This field is hash value of the name for the link. The hash value is the Jenkins’ lookup3 checksum algorithm applied to the link’s name.

ID

This is a 7-byte sequence of bytes and is the heap ID for the link record in the group’s fractal heap.

Creation Order

This field is the creation order value for the link.

ID

This is a 7-byte sequence of bytes and is the heap ID for the link record in the group’s fractal heap.

Message Location

This field Indicates the location where the message is stored:

Value	Description
0	Shared message is stored in shared message index heap.
1	Shared message is stored in object header.

Hash

This field is hash value of the shared message. The hash value is the Jenkins’ lookup3 checksum algorithm applied to the shared message.

Reference Count

The number of objects which reference this message.

Heap ID

This is an 8-byte sequence of bytes and is the heap ID for the shared message in the shared message index’s fractal heap.

Message Location

This field Indicates the location where the message is stored:

Value	Description
0	Shared message is stored in shared message index heap.
1	Shared message is stored in object header.

Hash

This field is hash value of the shared message. The hash value is the Jenkins’ lookup3 checksum algorithm applied to the shared message.

Message Type

The object header message type of the shared message.

Object Header Index

This field indicates that the shared message is the n^th message of its type in the specified object header.

Object Header Address

The address of the object header containing the shared message.

Heap ID

This is an 8-byte sequence of bytes and is the heap ID for the attribute in the object’s attribute fractal heap.

Message Flags

The object header message flags for the attribute message.

Creation Order

This field is the creation order value for the attribute.

Hash

This field is hash value of the name for the attribute. The hash value is the Jenkins’ lookup3 checksum algorithm applied to the attribute’s name.

Heap ID

This is an 8-byte sequence of bytes and is the heap ID for the attribute in the object’s attribute fractal heap.

Message Flags

The object header message flags for the attribute message.

Creation Order

This field is the creation order value for the attribute.

Signature

The ASCII character string “SNOD” is used to indicate the beginning of a symbol table node. This gives file consistency checking utilities a better chance of reconstructing a damaged file.

Version Number

The version number for the symbol table node. This document describes version 1. (There is no version ‘0’ of the symbol table node)

Number of Entries

Although all symbol table nodes have the same length, most contain fewer than the maximum possible number of link entries. This field indicates how many entries contain valid data. The valid entries are packed at the beginning of the symbol table node while the remaining entries contain undefined values.

Symbol Table Entries

Each link has an entry in the symbol table node. The format of the entry is described below. There are 2K entries in each group node, where K is the “Group Leaf Node K” value from the superblock.

Link Name Offset

This is the byte offset into the group’s local heap for the name of the link. The name is null terminated.

Object Header Address

Every object has an object header which serves as a permanent location for the object’s metadata. In addition to appearing in the object header, some of the object’s metadata can be cached in the scratch-pad space.

Cache Type

The cache type is determined from the object header. It also determines the format for the scratch-pad space:

Type	Description
0	No data is cached by the group entry. This is guaranteed to be the case when an object header has a link count greater than one.
1	Group object header metadata is cached in the scratch-pad space. This implies that the symbol table entry refers to another group.
2	The entry is a symbolic link. The first four bytes of the scratch-pad space are the offset into the local heap for the link value. The object header address will be undefined.

Reserved

These four bytes are present so that the scratch-pad space is aligned on an eight-byte boundary. They are always set to zero.

Scratch-pad Space

This space is used for different purposes, depending on the value of the Cache Type field. Any metadata about an object represented in the scratch-pad space is duplicated in the object header for that object.

Furthermore, no data is cached in the group entry scratch-pad space if the object header for the object has a link count greater than one.

Address of B-tree

This is the file address for the root of the group’s B-tree.

Address of Name Heap

This is the file address for the group’s local heap, in which are stored the group’s symbol names.

Offset to Link Value

The value of a symbolic link (that is, the name of the thing to which it points) is stored in the local heap. This field is the 4-byte offset into the local heap for the start of the link value, which is null terminated.

Signature

The ASCII character string “HEAP” is used to indicate the beginning of a heap. This gives file consistency checking utilities a better chance of reconstructing a damaged file.

Version

Each local heap has its own version number so that new heaps can be added to old files. This document describes version zero (0) of the local heap.

Data Segment Size

The total amount of disk memory allocated for the heap data. This may be larger than the amount of space required by the objects stored in the heap. The extra unused space in the heap holds a linked list of free blocks.

Offset to Head of Free-list

This is the offset within the heap data segment of the first free block (or the undefined address if there is no free block). The free block contains Size of Lengths bytes that are the offset of the next free block (or the value ‘1’ if this is the last free block) followed by Size of Lengths bytes that store the size of this free block. The size of the free block includes the space used to store the offset of the next free block and the size of the current block, making the minimum size of a free block 2 * Size of Lengths.

Address of Data Segment

The data segment originally starts immediately after the heap header, but if the data segment must grow as a result of adding more objects, then the data segment may be relocated, in its entirety, to another part of the file.

Signature

The ASCII character string “GCOL” is used to indicate the beginning of a collection. This gives file consistency checking utilities a better chance of reconstructing a damaged file.

Version

Each collection has its own version number so that new collections can be added to old files. This document describes version one (1) of the collections (there is no version zero (0)).

Collection Size

This is the size in bytes of the entire collection including this field. The default (and minimum) collection size is 4096 bytes which is a typical file system block size. This allows for 127 16-byte heap objects plus their overhead (the collection header of 16 bytes and the 16 bytes of information about each heap object).

Global Heap Object 1 through N

The objects are stored in any order with no intervening unused space.

Global Heap Object 0

Global Heap Object 0 (zero), when present, represents the free space in the collection. Free space always appears at the end of the collection. If the free space is too small to store the header for Object 0 (described below) then the header is implied and is not written.

The field Object Size for Object 0 indicates the amount of possible free space in the collection including the 16-byte header size of Object 0.

Heap Object Index

Each object has a unique identification number within a collection. The identification numbers are chosen so that new objects have the smallest value possible with the exception that the identifier 0 always refers to the object which represents all free space within the collection.

Reference Count

All heap objects have a reference count field. An object which is referenced from some other part of the file will have a positive reference count. The reference count for Object 0 is always zero.

Reserved

Zero padding to align next field on an 8-byte boundary.

Object Size

This is the size of the object data stored for the object. The actual storage space allocated for the object data is rounded up to a multiple of eight.

Object Data

The object data is treated as a one-dimensional array of bytes to be interpreted by the caller.

Signature

The ASCII character string “FRHP” is used to indicate the beginning of a fractal heap header. This gives file consistency checking utilities a better chance of reconstructing a damaged file.

Version

This document describes version 0.

Heap ID Length

This is the length in bytes of heap object IDs for this heap.

I/O Filters’ Encoded Length

This is the size in bytes of the encoded I/O Filter Information.

Flags

This field is the heap status flag and is a bit field indicating additional information about the fractal heap.

Bit(s)	Description
0	If set, the ID value to use for huge object has wrapped around. If the value for the Next Huge Object ID has wrapped around, each new huge object inserted into the heap will require a search for an ID value.
1	If set, the direct blocks in the heap are checksummed.
2-7	Reserved

Maximum Size of Managed Objects

This is the maximum size of managed objects allowed in the heap. Objects greater than this this are ‘huge’ objects and will be stored in the file directly, rather than in a direct block for the heap.

Next Huge Object ID

This is the next ID value to use for a huge object in the heap.

v2 B-tree Address of Huge Objects

This is the address of the v2 B-tree used to track huge objects in the heap. The type of records stored in the v2 B-tree will be determined by whether the address and length of a huge object can fit into a heap ID (if yes, it is a “directly” accessed huge object) and whether there is a filter used on objects in the heap.

Amount of Free Space in Managed Blocks

This is the total amount of free space in managed direct blocks (in bytes).

Address of Managed Block Free Space Manager

This is the address of the Free-space Manager for managed blocks.

Amount of Managed Space in Heap

This is the total amount of managed space in the heap (in bytes), essentially the upper bound of the heap’s linear address space.

Amount of Allocated Managed Space in Heap

This is the total amount of managed space (in bytes) actually allocated in the heap. This can be less than the Amount of Managed Space in Heap field, if some direct blocks in the heap’s linear address space are not allocated.

Offset of Direct Block Allocation Iterator in Managed Space

This is the linear heap offset where the next direct block should be allocated at (in bytes). This may be less than the Amount of Managed Space in Heap value because the heap’s address space is increased by a “row” of direct blocks at a time, rather than by single direct block increments.

Number of Managed Objects in Heap

This is the number of managed objects in the heap.

Size of Huge Objects in Heap

This is the total size of huge objects in the heap (in bytes).

Number of Huge Objects in Heap

This is the number of huge objects in the heap.

Size of Tiny Objects in Heap

This is the total size of tiny objects that are packed in heap IDs (in bytes).

Number of Tiny Objects in Heap

This is the number of tiny objects that are packed in heap IDs.

Table Width

This is the number of columns in the doubling table for managed blocks. This value must be a power of two.

Starting Block Size

This is the starting block size to use in the doubling table for managed blocks (in bytes). This value must be a power of two.

Maximum Direct Block Size

This is the maximum size allowed for a managed direct block. Objects inserted into the heap that are larger than this value (less the number of bytes of direct block prefix/suffix) are stored as ‘huge’ objects. This value must be a power of two.

Maximum Heap Size

This is the maximum size of the heap’s linear address space for managed objects (in bytes). The value stored is the log2 of the actual value, that is: the number of bits of the address space. ‘Huge’ and ‘tiny’ objects are not counted in this value, since they do not store objects in the linear address space of the heap.

Starting # of Rows in Root Indirect Block

This is the starting number of rows for the root indirect block. A value of 0 indicates that the root indirect block will have the maximum number of rows needed to address the heap’s Maximum Heap Size.

Address of Root Block

This is the address of the root block for the heap. It can be the undefined address if there is no data in the heap. It either points to a direct block (if the Current # of Rows in the Root Indirect Block value is 0), or an indirect block.

Current # of Rows in Root Indirect Block

This is the current number of rows in the root indirect block. A value of 0 indicates that Address of Root Block points to direct block instead of indirect block.

Size of Filtered Root Direct Block

This is the size of the root direct block, if filters are applied to heap objects (in bytes). This field is only stored in the header if the I/O Filters’ Encoded Length is greater than 0.

I/O Filter Mask

This is the filter mask for the root direct block, if filters are applied to heap objects. This mask has the same format as that used for the filter mask in chunked raw data records in a v1 B-tree. This field is only stored in the header if the I/O Filters’ Encoded Length is greater than 0.

I/O Filter Information

This is the I/O filter information encoding direct blocks and huge objects, if filters are applied to heap objects. This field is encoded as a Filter Pipeline message. The size of this field is determined by I/O Filters’ Encoded Length.

Checksum

This is the checksum for the header.

Signature

The ASCII character string “FHDB” is used to indicate the beginning of a fractal heap direct block. This gives file consistency checking utilities a better chance of reconstructing a damaged file.

Version

This document describes version 0.

Heap Header Address

This is the address for the fractal heap header that this block belongs to. This field is principally used for file integrity checking.

Block Offset

This is the offset of the block within the fractal heap’s address space (in bytes). The number of bytes used to encode this field is the Maximum Heap Size (in the heap’s header) divided by 8 and rounded up to the next highest integer, for values that are not a multiple of 8. This value is principally used for file integrity checking.

Checksum

This is the checksum for the direct block.

This field is only present if bit 1 of Flags in the heap’s header is set.

Object Data

This section of the direct block stores the actual data for objects in the heap. The size of this section is determined by the direct block’s size minus the size of the other fields stored in the direct block (for example, the Signature, Version, and others including the Checksum if it is present).

Signature

The ASCII character string “FHIB” is used to indicate the beginning of a fractal heap indirect block. This gives file consistency checking utilities a better chance of reconstructing a damaged file.

Version

This document describes version 0.

Heap Header Address

This is the address for the fractal heap header that this block belongs to. This field is principally used for file integrity checking.

Block Offset

This is the offset of the block within the fractal heap’s address space (in bytes). The number of bytes used to encode this field is the Maximum Heap Size (in the heap’s header) divided by 8 and rounded up to the next highest integer, for values that are not a multiple of 8. This value is principally used for file integrity checking.

Child Direct Block #K Address

This field is the address of the child direct block. The size of the [uncompressed] direct block can be computed by its offset in the heap’s linear address space.

Size of Filtered Direct Block #K

This is the size of the child direct block after passing through the I/O filters defined for this heap (in bytes). If no I/O filters are present for this heap, this field is not present.

Filter Mask for Direct Block #K

This is the I/O filter mask for the filtered direct block. This mask has the same format as that used for the filter mask in chunked raw data records in a v1 B-tree. If no I/O filters are present for this heap, this field is not present.

Child Indirect Block #N Address

This field is the address of the child indirect block. The size of the indirect block can be computed by its offset in the heap’s linear address space.

Checksum

This is the checksum for the indirect block.

Version, Type, and Length

This is a bit field with the following definition:

Bit	Description
6-7	The current version of ID format. This document describes version 0.
4-5	The ID type. Tiny objects have a value of 2.
0-3	The length of the tiny object. The value stored is one less than the actual length (since zero-length objects are not allowed to be stored in the heap). For example, an object of actual length 1 has an encoded length of 0, an object of actual length 2 has an encoded length of 1, and so on.

Data

This is the data for the object.

Version, Type, and Length

This is a bit field with the following definition:

Bit	Description
6-7	The current version of ID format. This document describes version 0.
4-5	The ID type. Tiny objects have a value of 2.
0-3	These 4 bits, together with the next byte, form an unsigned 12-bit integer for holding the length of the object. These 4-bits are bits 8-11 of the 12-bit integer. See description for the Extended Length field below.

Extended Length

This byte, together with the 4 bits in the previous byte, forms an unsigned 12-bit integer for holding the length of the tiny object. These 8 bits are bits 0-7 of the 12-bit integer formed. The value stored is one less than the actual length (since zero-length objects are not allowed to be stored in the heap). For example, an object of actual length 1 has an encoded length of 0, an object of actual length 2 has an encoded length of 1, and so on.

Data

This is the data for the object.

Version and Type

This is a bit field with the following definition:

Bit	Description
6-7	The current version of ID format. This document describes version 0.
4-5	The ID type. Huge objects have a value of 1.
0-3	Reserved.

v2 B-tree Key

This field is the B-tree key for retrieving the information from the version 2 B-tree for huge objects needed to access the object. See the description of v2 B-tree records sub-types 1 and 2 for a description of the fields. New key values are derived from Next Huge Object ID in the Fractal Heap Header.

Version and Type

This is a bit field with the following definition:

Bit	Description
6-7	The current version of ID format. This document describes version 0.
4-5	The ID type. Huge objects have a value of 1.
0-3	Reserved.

Address

This field is the address of the object in the file.

Length

This field is the length of the object in the file.

Version and Type

This is a bit field with the following definition:

Bit	Description
6-7	The current version of ID format. This document describes version 0.
4-5	The ID type. Huge objects have a value of 1.
0-3	Reserved.

Address

This field is the address of the filtered object in the file.

Length

This field is the length of the filtered object in the file.

Filter Mask

This field is the I/O pipeline filter mask for the filtered object in the file.

Filtered Size

This field is the size of the de-filtered object in the file.

Version and Type

This is a bit field with the following definition:

Bit	Description
6-7	The current version of ID format. This document describes version 0.
4-5	The ID type. Managed objects have a value of 0.
0-3	Reserved.

Offset

This field is the offset of the object in the heap. This field’s size is the minimum number of bytes necessary to encode the Maximum Heap Size value (from the Fractal Heap Header). For example, if the value of the Maximum Heap Size is less than 256 bytes, this field is 1 byte in length, a Maximum Heap Size of 256-65535 bytes uses a 2 byte length, and so on.

Length

This field is the length of the object in the heap. It is determined by taking the minimum value of Maximum Direct Block Size and Maximum Size of Managed Objects in the Fractal Heap Header. Again, the minimum number of bytes needed to encode that value is used for the size of this field.

Signature

The ASCII character string “FSHD” is used to indicate the beginning of the Free-space Manager Header. This gives file consistency checking utilities a better chance of reconstructing a damaged file.

Version

This is the version number for the Free-space Manager Header and this document describes version 0.

Client ID

This is the client ID for identifying the user of this free-space manager:

ID	Description
0	Fractal heap
1	File
2+	Reserved.

Total Space Tracked

This is the total amount of free space being tracked, in bytes.

Total Number of Sections

This is the total number of free-space sections being tracked.

Number of Serialized Sections

This is the number of serialized free-space sections being tracked.

Number of Un-Serialized Sections

This is the number of un-serialized free-space sections being managed. Un-serialized sections are created by the free-space client when the list of sections is read in.

Number of Section Classes

This is the number of section classes handled by this free space manager for the free-space client.

Shrink Percent

This is the percent of current size to shrink the allocated serialized free-space section list.

Expand Percent

This is the percent of current size to expand the allocated serialized free-space section list.

Size of Address Space

This is the size of the address space that free-space sections are within. This is stored as the log₂ of the actual value (in other words, the number of bits required to store values within that address space).

Maximum Section Size

This is the maximum size of a section to be tracked.

Address of Serialized Section List

This is the address where the serialized free-space section list is stored.

Size of Serialized Section List Used

This is the size of the serialized free-space section list used (in bytes). This value must be less than or equal to the allocated size of serialized section list, below.

Allocated Size of Serialized Section List

This is the size of serialized free-space section list actually allocated (in bytes).

Checksum

This is the checksum for the free-space manager header.

Signature

The ASCII character string “FSSE” is used to indicate the beginning of the Free-space Section Information. This gives file consistency checking utilities a better chance of reconstructing a damaged file.

Version

This is the version number for the Free-space Section List and this document describes version 0.

Free-space Manager Header Address

This is the address of the Free-space Manager Header. This field is principally used for file integrity checking.

Number of Section Records for Set #N

This is the number of free-space section records for set #N. The length of this field is the minimum number of bytes needed to store the number of serialized sections (from the free-space manager header).

The number of sets of free-space section records is determined by the size of serialized section list in the free-space manager header.

Section Size for Record Set #N

This is the size (in bytes) of the free-space section described for all the section records in set #N.

The length of this field is the minimum number of bytes needed to store the maximum section size (from the free-space manager header).

Record Set #N Section #K Offset

This is the offset (in bytes) of the free-space section within the client for the free-space manager.

The length of this field is the minimum number of bytes needed to store the size of address space (from the free-space manager header).

Record Set #N Section #K Type

This is the type of the section record, used to decode the record set #N section #K data information. The defined record type for file client is:

Type	Description
0	File’s section (a range of actual bytes in file)
1+	Reserved.

The defined record types for a fractal heap client are:

Type	Description
0	Fractal heap “single” section
1	Fractal heap “first row” section
2	Fractal heap “normal row” section
3	Fractal heap “indirect” section
4+	Reserved.

Record Set #N Section #K Data

This is the section-type specific information for each record in the record set, described below.

Checksum

This is the checksum for the Free-space Section List.

Fractal Heap Block Offset

The offset of the indirect block in the fractal heap’s address space containing the empty blocks.

The number of bytes used to encode this field is the minimum number of bytes needed to encode values for the Maximum Heap Size (in the fractal heap’s header).

Block Start Row

This is the row that the empty blocks start in.

Block Start Column

This is the column that the empty blocks start in.

Number of Blocks

This is the number of empty blocks covered by the section.

Signature

The ASCII character string “SMTB” is used to indicate the beginning of the Shared Object Header Message table. This gives file consistency checking utilities a better chance of reconstructing a damaged file.

Version for index #N

This is the version number for the list of shared object header message indexes and this document describes version 0.

Index Type for index #N

The type of index can be an unsorted list or a v2 B-tree.

Message Type Flags for index #N

This field indicates the type of messages tracked in the index, as follows:

Bits	Description
0	If set, the index tracks Dataspace Messages.
1	If set, the message tracks Datatype Messages.
2	If set, the message tracks Fill Value Messages.
3	If set, the message tracks Filter Pipeline Messages.
4	If set, the message tracks Attribute Messages.
5-15	Reserved (zero).

An index can track more than one type of message, but each type of message can only by in one index.

Minimum Message Size for index #N

This is the message size sharing threshold for the index. If the encoded size of the message is less than this value, the message is not shared.

List Cutoff for index #N

This is the cutoff value for the indexing of messages to switch from a list to a v2 B-tree. If the number of messages is greater than this value, the index should be a v2 B-tree.

v2 B-tree Cutoff for index #N

This is the cutoff value for the indexing of messages to switch from a v2 B-tree back to a list. If the number of messages is less than this value, the index should be a list.

Number of Messages for index #N

The number of shared messages being tracked for the index.

Index Address for index #N

This field is the address of the list or v2 B-tree where the index nodes reside.

Fractal Heap Address for index #N

This field is the address of the fractal heap if shared messages are stored there.

Checksum

This is the checksum for the table.

Signature

The ASCII character string “SMLI” is used to indicate the beginning of a list of index nodes. This gives file consistency checking utilities a better chance of reconstructing a damaged file.

Shared Message Record #N

The record for locating the shared message, either in the fractal heap for the index, or an object header (see format for index nodes below).

Checksum

This is the checksum for the list.

Message Location

This has a value of 0 indicating that the message is stored in the heap.

Hash Value

This is the hash value for the message.

Reference Count

This is the number of times the message is used in the file.

Fractal Heap ID

This is an 8-byte fractal heap ID for the message as stored in the fractal heap for the index.

Message Location

This has a value of 1 indicating that the message is stored in an object header.

Hash Value

This is the hash value for the message.

Message Type

This is the message type in the object header.

Creation Index

This is the creation index of the message within the object header.

Object Header Address

This is the address of the object header where the message is located.

Version

This value is used to determine the format of the information in the object header. When the format of the object header is changed, the version number is incremented and can be used to determine how the information in the object header is formatted. This is version one (1) (there was no version zero (0)) of the object header.

Total Number of Header Messages

This value determines the total number of messages listed in object headers for this object. This value includes the messages in continuation messages for this object.

Object Reference Count

This value specifies the number of “hard links” to this object within the current file. References to the object from external files, “soft links” in this file and object references in this file are not tracked.

Object Header Size

This value specifies the number of bytes of header message data following this length field that contain object header messages for this object header. This value does not include the size of object header continuation blocks for this object elsewhere in the file.

Header Message #n Type

This value specifies the type of information included in the following header message data. The message types for header messages are defined in sections below.

Size of Header Message #n Data

This value specifies the number of bytes of header message data following the header message type and length information for the current message. The size includes padding bytes to make the message a multiple of eight bytes.

Header Message #n Flags

This is a bit field with the following definition:

Bit	Description
0	If set, the message data is constant. This is used for messages like the datatype message of a dataset.
1	If set, the message is shared and stored in another location than the object header. The Header Message Data field contains a Shared Message (described in the Data Object Header Messages section below) and the Size of Header Message Data field contains the size of that Shared Message.
2	If set, the message should not be shared.
3	If set, the HDF5 decoder should fail to open this object if it does not understand the message’s type and the file is open with permissions allowing write access to the file. (Normally, unknown messages can just be ignored by HDF5 decoders)
4	If set, the HDF5 decoder should set bit 5 of this message’s flags (in other words, this bit field) if it does not understand the message’s type and the object is modified in any way. (Normally, unknown messages can just be ignored by HDF5 decoders)
5	If set, this object was modified by software that did not understand this message. (Normally, unknown messages should just be ignored by HDF5 decoders) (Can be used to invalidate an index or a similar feature)
6	If set, this message is shareable.
7	If set, the HDF5 decoder should always fail to open this object if it does not understand the message’s type (whether it is open for read-only or read-write access). (Normally, unknown messages can just be ignored by HDF5 decoders)

Header Message #n Data

The format and length of this field is determined by the header message type and size respectively. Some header message types do not require any data and this information can be eliminated by setting the length of the message to zero. The data is padded with enough zeroes to make the size a multiple of eight.

Signature

The ASCII character string “OHDR” is used to indicate the beginning of an object header. This gives file consistency checking utilities a better chance of reconstructing a damaged file.

Version

This field has a value of 2 indicating version 2 of the object header.

Flags

This field is a bit field indicating additional information about the object header.

Bit(s)	Description
0-1	This two bit field determines the size of the Size of Chunk #0 field. The values are: Value Description 0 The Size of Chunk #0 field is 1 byte. 1 The Size of Chunk #0 field is 2 bytes. 2 The Size of Chunk #0 field is 4 bytes. 3 The Size of Chunk #0 field is 8 bytes.
2	If set, attribute creation order is tracked.
3	If set, attribute creation order is indexed.
4	If set, non-default attribute storage phase change values are stored.
5	If set, access, modification, change and birth times are stored.
6-7	Reserved

Access Time

This 32-bit value represents the number of seconds after the UNIX epoch when the object’s raw data was last accessed (in other words, read or written).

This field is present if bit 5 of flags is set.

Modification Time

This 32-bit value represents the number of seconds after the UNIX epoch when the object’s raw data was last modified (in other words, written).

This field is present if bit 5 of flags is set.

Change Time

This 32-bit value represents the number of seconds after the UNIX epoch when the object’s metadata was last changed.

This field is present if bit 5 of flags is set.

Birth Time

This 32-bit value represents the number of seconds after the UNIX epoch when the object was created.

This field is present if bit 5 of flags is set.

Maximum # of compact attributes

This is the maximum number of attributes to store in the compact format before switching to the indexed format.

This field is present if bit 4 of flags is set.

Minimum # of dense attributes

This is the minimum number of attributes to store in the indexed format before switching to the compact format.

This field is present if bit 4 of flags is set.

Size of Chunk #0

This unsigned value specifies the number of bytes of header message data following this field that contain object header information.

This value does not include the size of object header continuation blocks for this object elsewhere in the file.

The length of this field varies depending on bits 0 and 1 of the flags field.

Header Message #n Type

Same format as version 1 of the object header, described above.

Size of Header Message #n Data

This value specifies the number of bytes of header message data following the header message type and length information for the current message. The size of messages in this version does not include any padding bytes.

Header Message #n Flags

Same format as version 1 of the object header, described above.

Header Message #n Creation Order

This field stores the order that a message of a given type was created in.

This field is present if bit 2 of flags is set.

Header Message #n Data

Same format as version 1 of the object header, described above.

Gap

A gap in an object header chunk is inferred by the end of the messages for the chunk before the beginning of the chunk’s checksum. Gaps are always smaller than the size of an object header message prefix (message type + message size + message flags).

Gaps are formed when a message (typically an attribute message) in an earlier chunk is deleted and a message from a later chunk that does not quite fit into the free space is moved into the earlier chunk.

Checksum

This is the checksum for the object header chunk.

Version

The version number is used when there are changes in the format of a shared object message and is described here:

Version	Description
0	Never used.
1	Used by the library before version 1.6.1.

Type

The type of shared message location:

Value	Description
0	Message stored in another object’s header (a committed message).

Address

The address of the object header containing the message to be shared.

Version

The version number is used when there are changes in the format of a shared object message and is described here:

Version	Description
2	Used by the library of version 1.6.1 and after.

Type

The type of shared message location:

Value	Description
0	Message stored in another object’s header (a committed message).

Address

The address of the object header containing the message to be shared.

Version

The version number indicates changes in the format of shared object message and is described here:

Version	Description
3	Used by the library of version 1.8 and after. In this version, the Type field can indicate that the message is stored in the fractal heap.

Type

The type of shared message location:

Value	Description
0	Message is not shared and is not shareable.
1	Message stored in file’s shared object header message heap (a shared message).
2	Message stored in another object’s header (a committed message).
3	Message stored is not shared, but is sharable.

Location

This field contains either a Size of Offsets-bytes address of the object header containing the message to be shared, or an 8-byte fractal heap ID for the message in the file’s shared object header message heap.

Version

This value is used to determine the format of the Dataspace Message. When the format of the information in the message is changed, the version number is incremented and can be used to determine how the information in the object header is formatted. This document describes version one (1) (there was no version zero (0)).

Dimensionality

This value is the number of dimensions that the data object has.

Flags

This field is used to store flags to indicate the presence of parts of this message. Bit 0 (the least significant bit) is used to indicate that maximum dimensions are present. Bit 1 is used to indicate that permutation indices are present.

Dimension #n Size

This value is the current size of the dimension of the data as stored in the file. The first dimension stored in the list of dimensions is the slowest changing dimension and the last dimension stored is the fastest changing dimension.

Dimension #n Maximum Size

This value is the maximum size of the dimension of the data as stored in the file. This value may be the special “unlimited” size which indicates that the data may expand along this dimension indefinitely. If these values are not stored, the maximum size of each dimension is assumed to be the dimension’s current size.

Permutation Index #n

This value is the index permutation used to map each dimension from the canonical representation to an alternate axis for each dimension. If these values are not stored, the first dimension stored in the list of dimensions is the slowest changing dimension and the last dimension stored is the fastest changing dimension.

Version

This value is used to determine the format of the Dataspace Message. This field should be ‘2’ for version 2 format messages.

Dimensionality

This value is the number of dimensions that the data object has.

Flags

This field is used to store flags to indicate the presence of parts of this message. Bit 0 (the least significant bit) is used to indicate that maximum dimensions are present.

Type

This field indicates the type of the dataspace:

Value	Description
0	A scalar dataspace; in other words, a dataspace with a single, dimensionless element.
1	A simple dataspace; in other words, a dataspace with a rank greater than 0 and an appropriate number of dimensions.
2	A null dataspace; in other words, a dataspace with no elements.

Dimension #n Size

This value is the current size of the dimension of the data as stored in the file. The first dimension stored in the list of dimensions is the slowest changing dimension and the last dimension stored is the fastest changing dimension.

Dimension #n Maximum Size

This value is the maximum size of the dimension of the data as stored in the file. This value may be the special “unlimited” size which indicates that the data may expand along this dimension indefinitely. If these values are not stored, the maximum size of each dimension is assumed to be the dimension’s current size.

Version

The version number for this message. This document describes version 0.

Flags

This field determines various optional aspects of the link info message:

Bit	Description
0	If set, creation order for the links is tracked.
1	If set, creation order for the links is indexed.
2-7	Reserved

Maximum Creation Index

This 64-bit value is the maximum creation order index value stored for a link in this group.

This field is present if bit 0 of flags is set.

Fractal Heap Address

This is the address of the fractal heap to store dense links. Each link stored in the fractal heap is stored as a Link Message.

If there are no links in the group, or the group’s links are stored “compactly” (as object header messages), this value will be the undefined address.

Address of v2 B-tree for Name Index

This is the address of the version 2 B-tree to index names of links.

If there are no links in the group, or the group’s links are stored “compactly” (as object header messages), this value will be the undefined address.

Address of v2 B-tree for Creation Order Index

This is the address of the version 2 B-tree to index creation order of links.

If there are no links in the group, or the group’s links are stored “compactly” (as object header messages), this value will be the undefined address.

This field exists if bit 1 of flags is set.

Class and Version

The version of the datatype message and the datatype’s class information are packed together in this field. The version number is packed in the top 4 bits of the field and the class is contained in the bottom 4 bits.

The version number information is used for changes in the format of the datatype message and is described here:

Version	Description
0	Never used
1	Used by early versions of the library to encode compound datatypes with explicit array fields. See the compound datatype description below for further details.
2	Used when an array datatype needs to be encoded.
3	Used when a VAX byte-ordered type needs to be encoded. Packs various other datatype classes more efficiently also.
4	Used to encode the revised reference datatype.

The class of the datatype determines the format for the class bit field and properties portion of the datatype message, which are described below. The following classes are currently defined:

Value	Description
0	Fixed-Point
1	Floating-Point
2	Time
3	String
4	Bit field
5	Opaque
6	Compound
7	Reference
8	Enumerated
9	Variable-Length
10	Array

Class Bit Fields

The information in these bit fields is specific to each datatype class and is described below. All bits not defined for a datatype class are set to zero.

Size

The size of a datatype element in bytes.

Properties

This variable-sized sequence of bytes encodes information specific to each datatype class and is described for each class below. If there is no property information specified for a datatype class, the size of this field is zero bytes.

Size

This is the size of the Fill Value field in bytes.

Fill Value

The fill value. The bytes of the fill value are interpreted using the same datatype as for the dataset.

Version

The version number information is used for changes in the format of the fill value message and is described here:

Version	Description
0	Never used
1	Initial version of this message.
2	In this version, the Size and Fill Value fields are only present if the Fill Value Defined field is set to 1.
3	This version packs the other fields in the message more efficiently than version 2.

Space Allocation Time

When the storage space for the dataset’s raw data will be allocated. The allowed values are:

Value	Description
0	Not used.
1	Early allocation. Storage space for the entire dataset should be allocated in the file when the dataset is created.
2	Late allocation. Storage space for the entire dataset should not be allocated until the dataset is written to.
3	Incremental allocation. Storage space for the dataset should not be allocated until the portion of the dataset is written to. This is currently used in conjunction with chunked data storage for datasets.

Fill Value Write Time

At the time that storage space for the dataset’s raw data is allocated, this value indicates whether the fill value should be written to the raw data storage elements. The allowed values are:

Value	Description
0	On allocation. The fill value is always written to the raw data storage when the storage space is allocated.
1	Never. The fill value should never be written to the raw data storage.
2	Fill value written if set by user. The fill value will be written to the raw data storage when the storage space is allocated only if the user explicitly set the fill value. If the fill value is the library default or is undefined, it will not be written to the raw data storage.

Fill Value Defined

This value indicates if a fill value is defined for this dataset. If this value is 0, the fill value is undefined. If this value is 1, a fill value is defined for this dataset. For version 2 or later of the fill value message, this value controls the presence of the Size and Fill Value fields.

Size

This is the size of the Fill Value field in bytes. This field is not present if the Version field is greater than 1, and the Fill Value Defined field is set to 0.

Fill Value

The fill value. The bytes of the fill value are interpreted using the same datatype as for the dataset. This field is not present if the Version field is greater than 1, and the Fill Value Defined field is set to 0.

Version

The version number information is used for changes in the format of the fill value message and is described here:

Version	Description
0	Never used
1	Initial version of this message.
2	In this version, the Size and Fill Value fields are only present if the Fill Value Defined field is set to 1.
3	This version packs the other fields in the message more efficiently than version 2.

Flags

When the storage space for the dataset’s raw data will be allocated. The allowed values are:

Bits	Description
0-1	Space Allocation Time, with the same values as versions 1 and 2 of the message.
2-3	Fill Value Write Time, with the same values as versions 1 and 2 of the message.
4	Fill Value Undefined, indicating that the fill value has been marked as “undefined” for this dataset. Bits 4 and 5 cannot both be set.
5	Fill Value Defined, with the same values as versions 1 and 2 of the message. Bits 4 and 5 cannot both be set.
6-7	Reserved (zero).

Size

This is the size of the Fill Value field in bytes. This field is not present if the Version field is greater than 1, and the Fill Value Defined flag is set to 0.

Fill Value

The fill value. The bytes of the fill value are interpreted using the same datatype as for the dataset. This field is not present if the Version field is greater than 1, and the Fill Value Defined flag is set to 0.

Version

The version number for this message. This document describes version 1.

Flags

This field contains information about the link and controls the presence of other fields below.

Bits	Description
0-1	Determines the size of the Length of Link Name field. Value Description 0 The size of the Length of Link Name field is 1 byte. 1 The size of the Length of Link Name field is 2 bytes. 2 The size of the Length of Link Name field is 4 bytes. 3 The size of the Length of Link Name field is 8 bytes.
2	Creation Order Field Present: if set, the Creation Order field is present. If not set, creation order information is not stored for links in this group.
3	Link Type Field Present: if set, the link is not a hard link and the Link Type field is present. If not set, the link is a hard link.
4	Link Name Character Set Field Present: if set, the link name is not represented with the ASCII character set and the Link Name Character Set field is present. If not set, the link name is represented with the ASCII character set.
5-7	Reserved (zero).

Link type

This is the link class type and can be one of the following values:

Value	Description
0	A hard link (should never be stored in the file)
1	A soft link.
2-63	Reserved for future HDF5 internal use.
64	An external link.
65-255	Reserved, but available for user-defined link types.

This field is present if bit 3 of Flags is set.

Creation Order

This 64-bit value is an index of the link’s creation time within the group. Values start at 0 when the group is created an increment by one for each link added to the group. Removing a link from a group does not change existing links’ creation order field.

This field is present if bit 2 of Flags is set.

Link Name Character Set

This is the character set for encoding the link’s name:

Value	Description
0	ASCII character set encoding (this should never be stored in the file)
1	UTF-8 character set encoding

This field is present if bit 4 of Flags is set.

Length of link name

This is the length of the link’s name. The size of this field depends on bits 0 and 1 of Flags.

Link name

This is the name of the link, non-NULL terminated.

Link information

The format of this field depends on the link type.

For hard links, the field is formatted as follows:

Size of Offsets bytes:

The address of the object header for the object that the link points to.

For soft links, the field is formatted as follows:

Bytes 1-2:	Length of soft link value.
Length of soft link value bytes:	A non-NULL-terminated string storing the value of the soft link.

For external links, the field is formatted as follows:

Bytes 1-2:

Length of external link value.

Length of external link value bytes:

The first byte contains the version number in the upper 4 bits and flags in the lower 4 bits for the external link. Both version and flags are defined to be zero in this document. The remaining bytes consist of two NULL-terminated strings, with no padding between them. The first string is the name of the HDF5 file containing the object linked to and the second string is the full path to the object linked to, within the HDF5 file’s group hierarchy.

For user-defined links, the field is formatted as follows:

Bytes 1-2:	Length of user-defined data.
Length of user-defined link value bytes:	The data supplied for the user-defined link type.

Version

The version number information is used for changes in the format of External Data Storage Message and is described here:

Version	Description
0	Never used.
1	The current version used by the library.

Allocated Slots

The total number of slots allocated in the message. Its value must be at least as large as the value contained in the Used Slots field. (The current library simply uses the number of Used Slots for this message)

Used Slots

The number of initial slots which contains valid information.

Heap Address

This is the address of a local heap which contains the names for the external files (The local heap information can be found in Disk Format Level 1D in this document). The name at offset zero in the heap is always the empty string.

Slot Definitions

The slot definitions are stored in order according to the array addresses they represent.

Name Offset in Local Heap

The byte offset within the local name heap for the name of the file. File names are stored as a URL which has a protocol name, a host name, a port number, and a file name: protocol:port//host/file. If the protocol is omitted then “file:” is assumed. If the port number is omitted then a default port for that protocol is used. If both the protocol and the port number are omitted then the colon can also be omitted. If the double slash and host name are omitted then “localhost” is assumed. The file name is the only mandatory part, and if the leading slash is missing then it is relative to the application’s current working directory (the use of relative names is not recommended).

Offset in External Data File

This is the byte offset to the start of the data in the specified file. For files that contain data for a single dataset this will usually be zero.

Data Size in External File

This is the total number of bytes reserved in the specified file for raw data storage. For a file that contains exactly one complete dataset which is not extendable, the size will usually be the exact size of the dataset. However, by making the size larger one allows HDF5 to extend the dataset. The size can be set to a value larger than the entire file since HDF5 will read zeroes past the end of the file without failing.