diff --git a/.github/workflows/netcdf.yml b/.github/workflows/netcdf.yml index 12f58ce25d4..f22f6dce913 100644 --- a/.github/workflows/netcdf.yml +++ b/.github/workflows/netcdf.yml @@ -52,6 +52,7 @@ jobs: -DHDF5_BUILD_DOC:BOOL=OFF \ -DHDF5_ENABLE_ZLIB_SUPPORT:BOOL=ON \ -DZLIB_USE_LOCALCONTENT:BOOL=OFF \ + -DHDF5_ENABLE_ZLIB_SUPPORT:BOOL=ON \ -DH5_NO_DEPRECATED_SYMBOLS:BOOL=OFF \ -DBUILD_TESTING:BOOL=OFF \ -DCMAKE_INSTALL_PREFIX:PATH=/usr/local \ diff --git a/CMakeFilters.cmake b/CMakeFilters.cmake index dcdbd011edd..3a6c00884ad 100644 --- a/CMakeFilters.cmake +++ b/CMakeFilters.cmake @@ -85,6 +85,7 @@ endif () if(NOT DEFINED ZLIBNG_PACKAGE_NAME) set(ZLIBNG_PACKAGE_NAME "zlib-ng") endif () +option (HDF5_ENABLE_ZLIB_SUPPORT "Enable Zlib Filters" OFF) if (HDF5_ENABLE_ZLIB_SUPPORT) if (NOT H5_ZLIB_HEADER) if (NOT ZLIB_USE_EXTERNAL) @@ -160,6 +161,7 @@ set(H5_SZIP_FOUND FALSE) if(NOT DEFINED LIBAEC_PACKAGE_NAME) set(LIBAEC_PACKAGE_NAME "libaec") endif () +option (HDF5_ENABLE_SZIP_SUPPORT "Use SZip Filter" OFF) if (HDF5_ENABLE_SZIP_SUPPORT) option (HDF5_ENABLE_SZIP_ENCODING "Use SZip Encoding" ON) if (NOT SZIP_USE_EXTERNAL) diff --git a/doxygen/dox/FileFormatSpec.dox b/doxygen/dox/FileFormatSpec.dox index fc10574dce2..308237c8d67 100644 --- a/doxygen/dox/FileFormatSpec.dox +++ b/doxygen/dox/FileFormatSpec.dox @@ -1,23 +1,7 @@ -/** \page FMT3 HDF5 File Format Specification Version 3.0 +\ref FMT3 -\htmlinclude H5.format.html +\ref FMT2 -*/ +\ref FMT11 -/** \page FMT2 HDF5 File Format Specification Version 2.0 - -\htmlinclude H5.format.2.0.html - -*/ - -/** \page FMT11 HDF5 File Format Specification Version 1.1 - -\htmlinclude H5.format.1.1.html - -*/ - -/** \page FMT1 HDF5 File Format Specification Version 1.0 - -\htmlinclude H5.format.1.0.html - -*/ \ No newline at end of file +\ref FMT1 diff --git a/doxygen/dox/H5.format.1.0.dox b/doxygen/dox/H5.format.1.0.dox new file mode 100644 index 00000000000..a5606b09a13 --- /dev/null +++ b/doxygen/dox/H5.format.1.0.dox @@ -0,0 +1,2469 @@ + +/** \page FMT1 HDF5 File Format Specification Version 1.0 +
    +
  1. @ref sec_fmt1_intro
    2. +
  2. @ref sec_fmt1_boot
    3. +
  3. @ref sec_fmt1_group +
      +
    1. @ref subsec_fmt1_group_btrees
      2. +
    2. @ref subsec_fmt1_group_symboltable
      3. +
    3. @ref subsec_fmt1_group_symboltableentry
      4. +
    4. @ref subsec_fmt1_group_localheap
      5. +
    5. @ref subsec_fmt1_group_globalheap
      6. +
    6. @ref subsec_fmt1_group_freespaceindex
      7. +
    4. +
  4. @ref sec_fmt1_dataobject +
      +
    1. @ref subsec_fmt1_dataobject_hdr +
        +
      1. @ref subsubsec_fmt1_dataobject_hdr_nil
        2. +
      2. @ref subsubsec_fmt1_dataobject_hdr_simple
        3. +
      3. @ref subsubsec_fmt1_dataobject_hdr_dtmessage
        4. +
      4. @ref subsubsec_fmt1_dataobject_hdr_fvmessage
        5. +
      5. @ref subsubsec_fmt1_dataobject_hdr_message_0005
        6. +
      6. @ref subsubsec_fmt1_dataobject_hdr_compact
        7. +
      7. @ref subsubsec_fmt1_dataobject_hdr_external
        8. +
      8. @ref subsubsec_fmt1_dataobject_hdr_layout
        9. +
      9. @ref subsubsec_fmt1_dataobject_hdr_message_0009
        10. +
      10. @ref subsubsec_fmt1_dataobject_hdr_message_000A
        11. +
      11. @ref subsubsec_fmt1_dataobject_hdr_filter
        12. +
      12. @ref subsubsec_fmt1_dataobject_hdr_attribute
        13. +
      13. @ref subsubsec_fmt1_dataobject_hdr_name
        14. +
      14. @ref subsubsec_fmt1_dataobject_hdr_modified
        15. +
      15. @ref subsubsec_fmt1_dataobject_hdr_shared
        16. +
      16. @ref subsubsec_fmt1_dataobject_hdr_continuation
        17. +
      17. @ref subsubsec_fmt1_dataobject_hdr_stmgroup
        18. +
      2. +
    2. @ref subsec_fmt1_dataobject_sharedhdr
      3. +
    3. @ref subsec_fmt1_dataobject_storage
      4. +
    +
    5. +
+ + + +\section sec_fmt1_intro Introduction + + + + + + + + + + + + + + +
Figure 1: Relationships among the HDF5 root group, other groups, and objects
\image html FF-IH_FileGroup.gif
Figure 2: HDF5 objects -- datasets, datatypes, or dataspaces
\image html FF-IH_FileObject.gif
+ +The format of an HDF5 file on disk encompasses several key ideas of the HDF4 and AIO file formats as well +as addressing some shortcomings therein. The new format is more self-describing than the HDF4 format and +is more uniformly applied to data objects in the file. + +An HDF5 file appears to the user as a directed graph. The nodes of this graph are the higher-level HDF5 +objects that are exposed by the HDF5 APIs: +\li Groups +\li Datasets +\li Datatypes +\li Dataspaces + +At the lowest level, as information is actually written to the disk, an HDF5 file is made up of the +following objects: +\li A super block +\li B-tree nodes (containing either symbol nodes or raw data chunks) +\li Object headers +\li Collections +\li Local heaps +\li Free space + +The HDF5 library uses these lower-level objects to represent the higher-level objects that are then +presented to the user or to applications through the APIs. For instance, a group is an object header that +contains a message that points to a local heap and to a B-tree which points to symbol nodes. A dataset is +an object header that contains messages that describe datatype, space, layout, filters, external files, +fill value, etc with the layout message pointing to either a raw data chunk or to a B-tree that points to +raw data chunks. + +\subsection subsec_fmt1_intro_doc This Document +This document describes the lower-level data objects; the higher-level objects and their properties are +described in the \ref UG. + +Three levels of information comprise the file format. Level 0 contains basic information for identifying +and defining information about the file. Level 1 information contains the group information (stored as +a B-tree) and is used as the index for all the objects in the file. Level 2 is the rest of the file and +contains all of the data objects, with each object partitioned into header information, also known as +meta information, and data. + +The sizes of various fields in the following layout tables are determined by looking at the number of +columns the field spans in the table. There are three exceptions: (1) The size may be overridden by +specifying a size in parentheses, (2) the size of addresses is determined by the Size of Offsets +field in the super block, and (3) the size of size fields is determined by the Size of Lengths +field in the super block. + +\section sec_fmt1_boot Disk Format: Level 0 - File Signature and Super Block +The super block may begin at certain predefined offsets within the HDF5 file, allowing a block of +unspecified content for users to place additional information at the beginning (and end) of the HDF5 file +without limiting the HDF5 library's ability to manage the objects within the file itself. This feature was +designed to accommodate wrapping an HDF5 file in another file format or adding descriptive information to +the file without requiring the modification of the actual file's information. The super block is located by +searching for the HDF5 file signature at byte offset 0, byte offset 512 and at successive locations in the +file, each a multiple of two of the previous location, i.e. 0, 512, 1024, 2048, etc. + +The super block is composed of a file signature, followed by super block and group version numbers, +information about the sizes of offset and length values used to describe items within the file, the size of +each group page, and a group entry for the root object in the file. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
HDF5 Super Block Layout
bytebytebytebyte

HDF5 File Signature (8 bytes)

Version \# of Super BlockVersion \# of Global Free-space StorageVersion \# of GroupReserved
Version \# of Shared Header Message FormatSize of OffsetsSize of LengthsReserved (zero)
Group Leaf Node KGroup Internal Node K
File Consistency Flags
Base Address*
Address of Global Free-space Heap*
End of File Address*
Driver Information Block Address*
Root Group Address*
+\li Items marked with an asterisk (*) in the above table are of the size specified in "Size of Offsets." + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
File SignatureThis 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: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
decimal13772687013102610
hexadecimal894844460d0a1a0a
ASCII C Notation\211HDF\\r\\n\032\\n
+
+ 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.)
Version Number of the Super BlockThis value is used to determine the format of the information in the super block. When the format of + the information in the super block is changed, the version number is incremented to the next integer + and can be used to determine how the information in the super block is formatted.
Version Number of the Global Free-space HeapThis value is used to determine the format of the information in the Global Free-space Heap.
Version Number of the GroupThis value is used to determine the format of the information in the Group. When the format of the + information in the Group is changed, the version number is incremented to the next integer and can be + used to determine how the information in the Group is formatted.
Version Number of the Shared Header Message FormatThis value is used to determine the format of the information in a shared object header message, which + is stored in the global small-data heap. Since the format of the shared header messages differs from + the private header messages, a version number is used to identify changes in the format.
Size of OffsetsThis 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 + super block signature. This allows a wrapper to be added after the file is created without invalidating + the internal offset locations.
Size of LengthsThis value contains the number of bytes used to store the size of an object.
Group Leaf Node KEach 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.
Group Internal Node KEach internal node of a group B-tree will have at least K pointers to other nodes but not more than 2K + pointers. If the group has only one internal node then it might have fewer than K pointers.
Bytes per B-tree PageThis value contains the number of bytes used for symbol pairs per page of the B-trees used in the file. + All B-tree pages will have the same size per page.
+ For 32-bit file offsets, 340 objects is the maximum per 4KB page; for 64-bit file offset, 254 objects + will fit per 4KB page. In general, the equation is:
+    <number of objects> =
       + FLOOR((<page size> - <offset size>) / +
          + (<Symbol size> + <offset size>)) - 1
File Consistency FlagsThis value contains flags to indicate information about the consistency of the information contained + within the file. Currently, the following bit flags are defined: +
    +
  • Bit 0 set indicates that the file is opened for write-access.
    • +
  • Bit 1 set indicates that the file has been verified for consistency and is guaranteed to be + consistent with the format defined in this document.
    • +
  • Bits 2-31 are reserved for future use.
    • +
+ Bit 0 should be set as the first action when a file is opened for write access and should be cleared + only as the final action when closing a file. Bit 1 should be cleared during normal access to a file + and only set after the file's consistency is guaranteed by the library or a consistency utility.
Base AddressThis 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 super block itself when creating + new files; future versions of the library may provide greater flexibility. Unless otherwise noted, all + other file addresses are relative to this base address.
Address of Global Free-space HeapFree-space management is not yet defined in the HDF5 file format and is not handled by the library. + Currently this field always contains the undefined address 0xfff...ff.
End of File AddressThis is the relative file address of the first byte past the end of all HDF5 data. It is used to + determine whether a file has been accidentally truncated and as an address where file data allocation + can occur if the free list is not used.
Driver Information Block AddressThis 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 (all bits set).
Root Group AddressThis is the address of the root group (described later in this document), which serves as the entry + point into the group graph.
+ +The file driver information block is an optional region of the file which contains information +needed by the file driver in order to reopen a file. The format of the file driver information block is: + + + + + + + + + + + + + + + + + + + + + +
Driver Information Block
bytebytebytebyte
VersionReserved (zero)
Driver Information Size (4 bytes)

Driver Identification (8 bytes)



Driver Information


+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number of the driver information block. The file format documented here is version zero.
Driver Information SizeThe size in bytes of the Driver Information part of this structure.
Driver IdentificationThis is an eight-byte ASCII string without null termination which identifies the driver and version number + of the Driver Information block. The predefined drivers supplied with the HDF5 library are 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. For example, the various versions of the family driver will be identified by + NCSAfami, NCSAfam0, NCSAfam1, etc. (NCSAfami is simply + NCSAfamily truncated to eight characters. Subsequent identifiers will be created by + substituting sequential numerical values for the final character, starting with zero.)
+ Identification for user-defined drivers is arbitrary but should be unique.
Driver InformationDriver information is stored in a format defined by the file driver and encoded/decoded by the driver + callbacks invoked from the H5FD_sb_encode and H5FD_sb_decode functions.
+ +\section sec_fmt1_group Disk Format: Level 1 - File Infrastructure + +\subsection subsec_fmt1_group_btrees Disk Format: Level 1A - B-link Trees and B-tree Nodes +B-link trees allow flexible storage for objects which tend to grow in ways that cause the object to be stored +discontiguously. B-trees are described in various algorithms books including "Introduction to Algorithms" by +Thomas H. Cormen, Charles E. Leiserson, and Ronald L. Rivest. The B-link tree, in which the sibling nodes at +a particular level in the tree are stored in a doubly-linked list, is described in the "Efficient Locking +for Concurrent Operations on B-trees" paper by Phillip Lehman and S. Bing Yao as published in the ACM +Transactions on Database Systems, Vol. 6, No. 4, December 1981. + +The B-link trees implemented by the file format contain one more key than the number of children. In other +words, each child pointer out of a B-tree node has a left key and a right key. The pointers out of internal +nodes point to sub-trees while the pointers out of leaf nodes point to symbol nodes and raw data chunks. +Aside from that difference, internal nodes and leaf nodes are identical. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
B-tree Nodes
bytebytebytebyte
Node Signature
Node TypeNode LevelEntries Used
Address of Left Sibling
Address of Right Sibling
Key 0 (variable size)
Address of Child 0
Key 1 (variable size)
Address of Child 1
...
Key 2K (variable size)
Address of Child 2K
Key 2K+1 (variable size)
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Node SignatureThe ASCII character string TREE is used to indicate the beginning of a B-link tree node. + This gives file consistency checking utilities a better chance of reconstructing a damaged file.
Node TypeEach B-link 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.
+
+
0
+
This tree points to group nodes.
+
1
+
This tree points to a new data chunk.
+
+
Node LevelThe 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 UsedThis 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 SiblingThis is the file address of the left sibling of the current node relative to the super block. If the + current node is the left-most node at this level then this field is the undefined address (all bits + set).
Address of Right SiblingThis is the file address of the right sibling of the current node relative to the super block. If the + current node is the right-most node at this level then this field is the undefined address (all bits + set).
Keys and Child PointersEach 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 Entries Used + field. If that field is N then the B-link tree contains N child pointers and + N+1 keys.
KeyThe 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 1, the key is formatted as follows: + + + + + + + + + + + + + +
Bytes 1-4Size of chunk in bytes.
Bytes 4-8Filter mask, a 32-bit bitfield indicating which filters have been applied to that chunk.
N fields of 8 bytes eachA 64-bit index indicating the offset of the chunk within the dataset where N is the number + of dimensions of the dataset. For example, if a chunk in a 3-dimensional dataset begins at the + position [5,5,5], there will be three such 8-bit indices, each with the value of + 5.
+
+ For nodes of node type 0, the key is formatted as follows: + + + + + +
A single field of Size of Lengths bytesIndicates the byte offset into the local heap for the first object name in the subtree which + that key describes.
+
Child PointersThe tree node contains file addresses of subtrees or data depending on the node level. Nodes at Level + 0 point to data addresses, either data chunk or group nodes. Nodes at non-zero levels point to other + nodes of the same B-tree.
+ +Each B-tree node looks like this: + + + + + + + + + + + + + +
key[0]  child[0]  key[1]  child[1]  key[2]  ...  ...  key[N-1]  child[N-1]  key[N]
+where child[i] is a pointer to a sub-tree (at a level above Level 0) or to data (at Level 0). +Each key[i] describes an item stored by the B-tree (a chunk or an object of a group node). +The range of values represented by child[i] are indicated by key[i] and key[i+1]. + +The following question must next be answered: "Is the value described by key[i] contained in +child[i-1] or in child[i]?" The answer depends on the type of tree. In trees for groups (node +type 0) the object described by key[i] is the greatest object contained in child[i-1] while +in chunk trees (node type 1) the chunk described by key[i] is the least chunk in child[i]. + +That means that key[0] for group trees is sometimes unused; it points to offset zero in the heap, which is +always the empty string and compares as "less-than" any valid object name. + +And key[N] for chunk trees is sometimes unused; it contains a chunk offset which compares as +"greater-than" any other chunk offset and has a chunk byte size of zero to indicate that it is not actually +allocated. + +\subsection subsec_fmt1_group_symboltable Disk Format: Level 1B - Group and Symbol Nodes +A group is an object internal to the file that allows arbitrary nesting of objects (including other groups). +A group maps a set of names to a set of file address relative to the base address. Certain meta data for an +object to which the group points can be duplicated in the group symbol table in addition to the object header. + +An HDF5 object name space can be stored hierarchically by partitioning the name into components and storing +each component in a group. The group entry for a non-ultimate component points to the group containing the +next component. The group entry for the last component points to the object being named. + +A group is a collection of group nodes pointed to by a B-link tree. Each group node contains entries for one +or more symbols. If an attempt is made to add a symbol to an already full group node containing 2K +entries, then the node is split and one node contains K symbols and the other contains K+1 +symbols. + + + + + + + + + + + + + + + + + + + + +
Group Node (A Leaf of a B-tree)
bytebytebytebyte
Node Signature
Version NumberReserved for Future UseNumber of Symbols


Group Entries


+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Node SignatureThe ASCII character string SNOD is used to indicate the beginning of a group node. This + gives file consistency checking utilities a better chance of reconstructing a damaged file.
Version NumberThe version number for the group node. This document describes version 1.
Number of SymbolsAlthough all group nodes have the same length, most contain fewer than the maximum possible number of + symbol entries. This field indicates how many entries contain valid data. The valid entries are packed + at the beginning of the group node while the remaining entries contain undefined values.
Group EntriesEach symbol has an entry in the group node. The format of the entry is described below.
+ +\subsection subsec_fmt1_group_symboltableentry Disk Format: Level 1C - Group Entry +Each group entry in a group node is designed to allow for very fast browsing of stored objects. Toward that +design goal, the group entries include space for caching certain constant meta data from the object header. + + + + + + + + + + + + + + + + + + + + + + + + +
Group Entry
bytebytebytebyte
Name Offset (<size> bytes)
Object Header Address
Cache Type
Reserved


Scratch-pad Space (16 bytes)


+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Name OffsetThis is the byte offset into the group local heap for the name of the object. The name is null + terminated.
Object Header AddressEvery object has an object header which serves as a permanent location for the object's meta data. + In addition to appearing in the object header, some meta data can be cached in the scratch-pad space.
Cache TypeThe cache type is determined from the object header. It also determines the format for the scratch-pad + space.
+
+
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
+
Object header meta data is cached in the group entry. This implies that the group 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.
+
N
+
Other cache values can be defined later and libraries that do not understand the new values will + still work properly.
+
+
ReservedThese 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 SpaceThis space is used for different purposes, depending on the value of the Cache Type field. Any meta-data + about a dataset object represented in the scratch-pad space is duplicated in the object header for + that dataset. This meta data can include the datatype and the size of the dataspace for a dataset whose + datatype is atomic and whose dataspace is fixed and less than four dimensions. Furthermore, no data is + cached in the group entry scratch-pad space if the object header for the group entry has a link count + greater than one.
+ +\subsubsection subsubsec_fmt1_group_symboltableentry_scratch Format of the Scratch-pad Space +The group entry scratch-pad space is formatted according to the value in the Cache Type field. + +If the Cache Type field contains the value zero (0) then no information is stored in the +scratch-pad space. + +If the Cache Type field contains the value one (1), then the scratch-pad space contains +cached meta data for another object header in the following format: + + + + + + + + + + + + + +
Object Header Scratch-pad Format
bytebytebytebyte
Address of B-tree
Address of Name Heap
+ + + + + + + + + + + + + + +
Field NameDescription
Address of B-treeThis is the file address for the root of the group's B-tree.
Address of Name HeapThis is the file address for the group's local heap, in which are stored the symbol names.
+ +If the Cache Type field contains the value two (2), then the scratch-pad space contains +cached meta data for another symbolic link in the following format: + + + + + + + + + + + +
Symbolic Link Scratch-pad Format
bytebytebytebyte
Offset to Link Value
+ + + + + + + + + + +
Field NameDescription
Offset to Link ValueThe 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.
+ +\subsection subsec_fmt1_group_localheap Disk Format: Level 1D - Local Heaps +A heap is a collection of small heap objects. Objects can be inserted and removed from the heap at any time. +The address of a heap does not change once the heap is created. References to objects are stored in the group +table; the names of those objects are stored in the local heap. + + + + + + + + + + + + + + + + + + + + + + + +
Local Heaps
bytebytebytebyte
Heap Signature
Reserved (zero)
Data Segment Size
Offset to Head of Free-list (<size> bytes)
Address of Data Segment
+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Heap SignatureThe 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.
Data Segment SizeThe total amount of disk memory allocated for the heap data. This may be larger than the amount of space + required by the object stored in the heap. The extra unused space holds a linked list of free blocks.
Offset to Head of Free-listThis is the offset within the heap data segment of the first free block (or all 0xff bytes if there is + no free block). The free block contains <size> bytes that are the offset of the next free chunk + (or all 0xff bytes if this is the last free chunk) followed by <size> bytes that store the size + of this free chunk.
Address of Data SegmentThe 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.
+ +Objects within the heap should be aligned on an 8-byte boundary. + +\subsection subsec_fmt1_group_globalheap Disk Format: Level 1E - Global Heap +Each HDF5 file has a global heap which stores various types of information which is typically shared between +datasets. The global heap was designed to satisfy these goals: +
    +
  1. Repeated access to a heap object must be efficient without resulting in repeated file I/O requests. + Since global heap objects will typically be shared among several datasets, it is probable that the + object will be accessed repeatedly.
    2. +
  2. Collections of related global heap objects should result in fewer and larger I/O requests. For + instance, a dataset of void pointers will have a global heap object for each pointer. Reading the + entire set of void pointer objects should result in a few large I/O requests instead of one small + I/O request for each object.
    3. +
  3. It should be possible to remove objects from the global heap and the resulting file hole should be + eligible to be reclaimed for other uses.
    4. +
+ +The implementation of the heap makes use of the memory management already available at the file level and +combines that with a new top-level object called a collection to achieve Goal B. The global heap is +the set of all collections. Each global heap object belongs to exactly one collection and each collection +contains one or more global heap objects. For the purposes of disk I/O and caching, a collection is treated +as an atomic object. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
A Global Heap Collection
bytebytebytebyte
Magic Number
VersionReserved
Collection Size

Global Heap Object 1 (described below)


Global Heap Object 2


...


Global Heap Object N


Global Heap Object 0 (free space)

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Magic NumberThe magic number for global heap collections are the four bytes G, C, + O, and L.
VersionEach collection has its own version number so that new collections can be added to old files. This + document describes version zero of the collections.
Collection Data SizeThis 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 and which allows for 170 16-byte + heap objects plus their overhead.
Object 1 through NThe objects are stored in any order with no intervening unused space.
Object 0Object 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 the collection contains no free space.
+ + + + + + + + + + + + + + + + + + + + + + +
Global Heap Object
bytebytebytebyte
Object IDReference Count
Reserved
Object Data Size

Object Data

+ + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Object IDEach 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 CountAll 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.
ReservedZero padding to align next field on an 8-byte boundary.
Object Size This is the size of the fields above plus the object data stored for the object. + The actual storage size is rounded up to a multiple of eight.
Object DataThe object data is treated as a one-dimensional array of bytes to be interpreted by the caller.
+ +\subsection subsec_fmt1_group_freespaceindex Disk Format: Level 1F - Free-space Heap +The Free-space Index is a collection of blocks of data, dispersed throughout the file, which are currently +not used by any file objects. + +The super block contains a pointer to root of the free-space description; that pointer is currently (i.e., in +HDF5 Release 1.2) required to be the undefined address 0xfff...ff. + +The free-sapce index is not otherwise publicly defined at this time. + +\section sec_fmt1_dataobject Disk Format: Level 2 - Data Objects +Data objects contain the real information in the file. These objects compose the scientific data and other +information which are generally thought of as "data" by the end-user. All the other information in the file +is provided as a framework for these data objects. + +A data object is composed of header information and data information. The header information contains the +information needed to interpret the data information for the data object as well as additional "meta-data" +or pointers to additional "meta-data" used to describe or annotate each data object. + +\subsection subsec_fmt1_dataobject_hdr Disk Format: Level 2a - Data Object Headers +The header information of an object is designed to encompass all the information about an object which would +be desired to be known, except for the data itself. This information includes the dimensionality, number-type, +information about how the data is stored on disk (in external files, compressed, broken up in blocks, etc.), +as well as other information used by the library to speed up access to the data objects or maintain a file's +integrity. The header of each object is not necessarily located immediately prior to the object's data in the +file and in fact may be located in any position in the file. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Object Headers
bytebytebytebyte
Version \# of Object HeaderReservedNumber of Header Messages
Object Reference Count

Total Object Header Size

Header Message Type \#1Size of Header Message Data \#1
FlagsReserved

Header Message Data \#1

.
.
.
Header Message Type \#nSize of Header Message Data \#n
FlagsReserved

Header Message Data \#n

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Version number of the object headerThis value is used to determine the format of the information in the object header. When the format of + the information in 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.
ReservedAlways set to zero.
Number of header messagesThis value determines the number of messages listed in this object header. This provides a fast way for + software to prepare storage for the messages in the header.
Object Reference CountThis value specifies the number of references to this object within the current file. References to the + data object from external files are not tracked.
Total Object Header SizeThis value specifies the total number of bytes of header message data following this length field for the + current message as well as any continuation data located elsewhere in the file.
Header Message TypeThe header message type specifies the type of information included in the header message data following + the type along with a small amount of other information. Bit 15 of the message type is set if the message + is constant (constant messages cannot be changed since they may be cached in group entries throughout the + file). The header message types for the pre-defined header messages will be included in further discussion + below.
Size of Header Message DataThis 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.
FlagsThis is a bit field with the following definition: +
+
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 stored in the global heap and the Header Message Data field contains a + Shared Object message and the Size of Header Message Data field contains the size of that Shared + Object message.
+
2-7
+
Reserved
+
+
Header Message DataThe 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 zeros to make the size a multiple of + eight.
+ +The header message types and the message data associated with them compose the critical "meta-data" about +each object. Some header messages are required for each object while others are optional. Some optional +header messages may also be repeated several times in the header itself, the requirements and number of +times allowed in the header will be noted in each header message description below. + +The following is a list of currently defined header messages: + +\subsubsection subsubsec_fmt1_dataobject_hdr_nil Name: NIL +Type: 0x0000
+Length: varies
+Status: Optional, may be repeated.
+Purpose and Description: The NIL message is used to indicate a message which is to be ignored +when reading the header messages for a data object. [Probably one which has been deleted for some reason.]
+Format of Data: Unspecified.
+ +\subsubsection subsubsec_fmt1_dataobject_hdr_simple Name: Simple Dataspace +Type: 0x0001
+Length: Varies according to the number of dimensions, as described in the following table
+Status: The Simple Dataspace message is required and may not be repeated. This message +is currently used with datasets and named dataspaces.
+ +The Simple Dataspace message describes the number of dimensions and size of each dimension that the +data object has. This message is only used for datasets which have a simple, rectilinear grid layout; datasets +requiring a more complex layout (irregularly structured or unstructured grids, etc.) must use the +Complex Dataspace message for expressing the space the dataset inhabits. (Note: The +Complex Dataspace functionality is not yet implemented (as of HDF5 Release 1.2). It is not described +in this document.) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Simple Dataspace Message
bytebytebytebyte
VersionDimensionalityFlagsReserved
Reserved
Dimension Size \#1 (<size> bytes)
.
.
.
Dimension Size \#n (<size> bytes)
Dimension Maximum \#1 (<size> bytes)
.
.
.
Dimension Maximum \#n (<size> bytes)
Permutation Index \#1
.
.
.
Permutation Index \#n
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Version This value is used to determine the format of the Simple 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.
DimensionalityThis value is the number of dimensions that the data object has.
FlagsThis 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 for each dimension.
Dimension Size \#n (<size> bytes)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 Maximum \#n (<size> bytes)This value is the maximum size of the dimension of the data as stored in the file. This value may be + the special value <UNLIMITED> (all bits set) which indicates that the data may expand along this + dimension indefinitely. If these values are not stored, the maximum value of each dimension is assumed + to be the same as the current size value.
Permutation Index \#n (4 bytes)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.
+ +\subsubsection subsubsec_fmt1_dataobject_hdr_dtmessage Name: Datatype +Type: 0x0003
+Length: variable
+Status: One required per dataset or named datatype
+ +The datatype message defines the datatype for each data point of a dataset. A datatype can describe an atomic +type like a fixed- or floating-point type or a compound type like a C struct. A datatype does not, however, +describe how data points are combined to produce a dataset. Datatypes are stored on disk as a datatype message, +which is a list of datatype classes and their associated properties. + + + + + + + + + + + + + + + + + + + +
Datatype Message
bytebytebytebyte
Type Class and VersionClass Bit Field
Size in Bytes (4 bytes)


Properties

/
+ +The Class Bit Field and Properties fields vary depending on the Type Class, which is the low-order four bits +of the Type Class and Version field (the high-order four bits are the version, which should be set to the +value one). The type class is one of 0 (fixed-point number), 1 (floating-point number), 2 (date and time), +3 (text string), 4 (bit field), 5 (opaque), 6 (compound), 7 (reference), 8 (enumeration), or 9 +(variable-length). The Class Bit Field is zero and the size of the Properties field is zero except for the +cases noted here. + + + + + + + + + + + + + + + + + + + + + + + +
+ Bit Field for Fixed-point Numbers (Class 0) +
BitsMeaning
0Byte Order. If zero, byte order is little-endian; otherwise, byte order is big endian.
1, 2Padding type. Bit 1 is the lo_pad type and bit 2 is the hi_pad type. If a datum has + unused bits at either end, then the lo_pad or hi_pad bit is copied to those locations.
3Signed. If this bit is set then the fixed-point number is in 2's complement form.
4-23Reserved (zero).
+ + + + + + + + + + + + + +
+ Properties for Fixed-point Numbers (Class 0) +
ByteByteByteByte
Bit OffsetBit Precision
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Bit Field for Floating-point Numbers (Class 1)
BitsMeaning
0Byte Order. If zero, byte order is little-endian; otherwise, byte order is big endian.
1, 2, 3Padding type. Bit 1 is the low bits pad type, bit 2 is the high bits pad type, and bit + 3 is the internal bits pad type. If a datum has unused bits at either or between the sign bit, exponent, + or mantissa, then the value of bit 1, 2, or 3 is copied to those locations.
4-5Normalization. The value can be 0 if there is no normalization, 1 if the most significant + bit of the mantissa is always set (except for 0.0), and 2 if the most significant bit of the mantissa is not + stored but is implied to be set. The value 3 is reserved and will not appear in this field.
6-7Reserved (zero).
8-15Sign. This is the bit position of the sign bit.
16-23Reserved (zero).
+ + + + + + + + + + + + + + + + + + + + + + +
Properties for Floating-point Numbers (Class 1)
ByteByteByteByte
Bit OffsetBit Precision
Exponent LocationExponent Size in BitsMantissa LocationMantissa Size in Bits
Exponent Bias
+ + + + + + + + + + + + + + + + + + +
Bit Field for Strings (Class 3)
BitsMeaning
0-3Padding type. This four-bit value determines the type of padding to use for the + string. The values are: +
+
0 Null terminate.
+
A zero byte marks the end of the string and is guaranteed to be present after converting a long + string to a short string. When converting a short string to a long string the value is padded with + additional null characters as necessary.
+
1 Null pad.
+
Null characters are added to the end of the value during conversions from short values to long values + but conversion in the opposite direction simply truncates the value.
+
2 Space pad.
+
Space characters are added to the end of the value during conversions from short values to long values + but conversion in the opposite direction simply truncates the value. This is the Fortran + representation of the string.
+
3-15 Reserved.
+
These values are reserved for future use.
+
+
4-7Character Set. The character set to use for encoding the string. The only character set + supported is the 8-bit ASCII (zero) so no translations have been defined yet.
8-23Reserved (zero).
+ + + + + + + + + + + + + + + + + + + +
Bit Field for Bitfield Types (Class 4)
BitsMeaning
0Byte Order. If zero, byte order is little-endian; otherwise, byte order is big endian.
1, 2Padding type. Bit 1 is the lo_pad type and bit 2 is the hi_pad type. If a datum has + unused bits at either end, then the lo_pad or hi_pad bit is copied to those locations.
3-23Reserved (zero).
+ + + + + + + + + + + + + +
Properties for Bitfield Types (Class 4)
ByteByteByteByte
Bit OffsetBit Precision
+ + + + + + + + + + + +
Bit Field for Opaque Types (Class 5)
BitsMeaning
0-23Reserved (zero).
+ + + + + + + + + + + + +
Properties for Opaque Types (Class 5)
ByteByteByteByte

Null-terminated ASCII Tag
(multiple of 8 bytes)

+ + + + + + + + + + + + + + + +
Bit Field for Compound Types (Class 6)
BitsMeaning
0-15Number of Members. This field contains the number of members defined for the + compound datatype. The member definitions are listed in the Properties field of the data type + message.
15-23Reserved (zero).
+ +The Properties field of a compound datatype is a list of the member definitions of the compound datatype. +The member definitions appear one after another with no intervening bytes. The member types are described +with a recursive datatype message. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Properties for Compound Types (Class 6)
ByteByteByteByte


Name (null terminated, multiple of eight bytes)

/
Byte Offset of Member in Compound Instance
Dimensionalityreserved
Dimension Permutation
Reserved
Size of Dimension 0 (required)
Size of Dimension 1 (required)
Size of Dimension 2 (required)
Size of Dimension 3 (required)


Member Type Message


+ + + + + + + + + + + + + + + +
Bit Field for Enumeration Types (Class 8)
BitsMeaning
0-15Number of Members. The number of name/value pairs defined for the enumeration type.
16-23Reserved (zero).
+ + + + + + + + + + + + + + + + + + +
Properties for Enumeration Types (Class 8)
ByteByteByteByte

Parent Type


Names


Values

+ + + + + + + + + + + + + + +
Parent Type:Each enumeration type is based on some parent type, usually an integer. The information + for that parent type is described recursively by this field.
Names:The name for each name/value pair. Each name is stored as a null terminated ASCII string + in a multiple of eight bytes. The names are in no particular order.
Values:The list of values in the same order as the names. The values are packed (no inter-value + padding) and the size of each value is determined by the parent type.
+ + + + + + + + + + + + + + + + + + + + + + + +
Bit Field for Variable-length Types (Class 9)
BitsMeaning
0-3 +
+
Type
+
0 Variable-length sequence
+
This variable-length datatype can be of any sequence of data. Variable-length sequences do not + have padding or character set information.
+
1 Variable-length string
+
This variable-length datatype is composed of a series of characters. Variable-length strings + have padding and character set information.
+
4-7 +
+
Padding type (variable-length string only)
+
This four-bit value determines the type of padding used for variable-length strings. The values + are the same as for the string padding type, as follows:
+
0 Null terminate
+
A zero byte marks the end of a string and is guaranteed to be present after converting a long + string to a short string. When converting a short string to a long string, the value is padded + with additional null characters as necessary.
+
1 Null pad
+
Null characters are added to the end of the value during conversion from a short string to a + longer string. Conversion from a long string to a shorter string simply truncates the value.
+
2 Space pad
+
Space characters are added to the end of the value during conversion from a short string to a + longer string. Conversion from a long string to a shorter string simply truncates the value. + This is the Fortran representation of the string.
+
3-15 Reserved
+
These values are reserved for future use.
+
8-11 +
+
Character set (variable-length string only)
+
This four-bit value specifies the character set to be used for encoding the string.
+
0 8-bit ASCII
+
As of this writing (July 2002, Release 1.4.4), 8-bit ASCII is the only character set supported. + Therefore, no translations have been defined.
+
12-23Reserved (zero).
+ + + + + + + + + + + + +
Properties for Variable-length Types (Class 9)
ByteByteByteByte

Parent Type

+ + + + + + +
Parent Type:Each variable-length type is based on some parent type. The information for that parent + type is described recursively by this field.
+ +\subsubsection subsubsec_fmt1_dataobject_hdr_fvmessage Name: Data Storage - Fill Value +Type: 0x0004
+Length: varies
+Status: Optional, may not be repeated.
+ +The fill value message stores a single data point value which is returned to the application when an +uninitialized data point is read from the dataset. The fill value is interpreted with the same datatype as +the dataset. If no fill value message is present then a fill value of all zero is assumed. + + + + + + + + + + + + + + + +
Fill Value Message
bytebytebytebyte
Size (4 bytes)

Fill Value

+
+ + + + + + + + + + + + + +
Field NameDescription
Size (4 bytes)This is the size of the Fill Value field in bytes.
Fill ValueThe fill value. The bytes of the fill value are interpreted using the same datatype as for the dataset.
+ +\subsubsection subsubsec_fmt1_dataobject_hdr_message_0005 Name: Reserved - Not Assigned Yet +Type: 0x0005
+Length: N/A
+Status: N/A
+ +\subsubsection subsubsec_fmt1_dataobject_hdr_compact Name: Data Storage - Compact +Type: 0x0006
+Length: varies
+Status: Optional, may not be repeated.
+ +This message indicates that the data for the data object is stored within the current HDF file by including +the actual data as the header data for this message. The data is stored internally in the normal +format, i.e. in one chunk, uncompressed, etc. + +Note that one and only one of the Data Storage headers can be stored for each data object. + +Format of Data: The message data is actually composed of dataset data, so the format will +be determined by the dataset format. + +\subsubsection subsubsec_fmt1_dataobject_hdr_external Name: Data Storage - External Data Files +Type: 0x0007
+Length: varies
+Status: Optional, may not be repeated.
+ +

Purpose and Description: The external object message indicates that the data for an +object is stored outside the HDF5 file. The filename of the object is stored as a Universal Resource Location +(URL) of the actual filename containing the data. An external file list record also contains the byte offset +of the start of the data within the file and the amount of space reserved in the file for that data. + + + + + + + + + + + + + + + + + + + + + + + +
External File List Message
bytebytebytebyte
VersionReserved
Allocated SlotsUsed Slots

Heap Address


Slot Definitions...

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThis value is used to determine the format of the External File List 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.
ReservedThis field is reserved for future use.
Allocated SlotsThe 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.
Used SlotsThe number of initial slots which contain valid information. The remaining slots are zero filled.
Heap AddressThis is the address of a local name heap which contains the names for the external files. The name at + offset zero in the heap is always the empty string.
Slot DefinitionsThe slot definitions are stored in order according to the array addresses they represent. If more slots + have been allocated than what has been used then the defined slots are all at the beginning of the list.
+ + + + + + + + + + + + + + + + + + +
External File List Slot
bytebytebytebyte

Name Offset (<size> bytes)


File Offset (<size> bytes)


Size

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
Name Offset (<size> bytes)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).
File Offset (<size> bytes)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.
SizeThis 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 zeros past the end of the file without failing.
+ +\subsubsection subsubsec_fmt1_dataobject_hdr_layout Name: Data Storage - Layout +Type: 0x0008
+Length: varies
+Status: Required for datasets, may not be repeated. + +Purpose and Description: Data layout describes how the elements of a multi-dimensional array +are arranged in the linear address space of the file. Two types of data layout are supported: +

    +
  1. The array can be stored in one contiguous area of the file. The layout requires that the size of the + array be constant and does not permit chunking, compression, checksums, encryption, etc. The message + stores the total size of the array and the offset of an element from the beginning of the storage area + is computed as in C.
    2. +
  2. The array domain can be regularly decomposed into chunks and each chunk is allocated separately. This + layout supports arbitrary element traversals, compression, encryption, and checksums, and the chunks + can be distributed across external raw data files (these features are described in other messages). + The message stores the size of a chunk instead of the size of the entire array; the size of the entire + array can be calculated by traversing the B-tree that stores the chunk addresses.
    3. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Data Layout Message
bytebytebytebyte
VersionDimensionalityLayout ClassReserved
Reserved

Address

Dimension 0 (4-bytes)
Dimension 1 (4-bytes)
...
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionA version number for the layout message. This documentation describes version one.
DimensionalityAn array has a fixed dimensionality. This field specifies the number of dimension size fields later + in the message.
Layout ClassThe layout class specifies how the other fields of the layout message are to be interpreted. A value + of one indicates contiguous storage while a value of two indicates chunked storage. Other values will + be defined in the future.
AddressFor contiguous storage, this is the address of the first byte of storage. For chunked storage this is + the address of the B-tree that is used to look up the addresses of the chunks.
DimensionsFor contiguous storage the dimensions define the entire size of the array while for chunked storage + they define the size of a single chunk.
+ +\subsubsection subsubsec_fmt1_dataobject_hdr_message_0009 Name: Reserved - Not Assigned Yet +Type: 0x0009
+Length: N/A
+Status: N/A
+Purpose and Description: N/A
+Format of Data: N/A + +\subsubsection subsubsec_fmt1_dataobject_hdr_message_000A Name: Reserved - Not Assigned Yet +Type: 0x000A
+Length: N/A
+Status: N/A
+Purpose and Description: N/A
+Format of Data: N/A + +\subsubsection subsubsec_fmt1_dataobject_hdr_filter Name: Data Storage - Filter Pipeline +Type: 0x000B
+Length: varies
+Status: Optional, may not be repeated. + +Purpose and Description: This message describes the filter pipeline which should be +applied to the data stream by providing filter identification numbers, flags, a name, an client data. + + + + + + + + + + + + + + + + + + + + +
Filter Pipeline Message
bytebytebytebyte
VersionNumber of FiltersReserved
Reserved

Filter List

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number for this message. This document describes version one.
Number of FiltersThe total number of filters described by this message. The maximum possible number of filters in a + message is 32.
Filter ListA description of each filter. A filter description appears in the next table.
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Filter Pipeline Message
bytebytebytebyte
Filter IdentificationName Length
FlagsClient Data Number of Values

Name


Client Data

Padding
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Filter IdentificationThis is a unique (except in the case of testing) identifier for the filter. Values from zero through + 255 are reserved for filters defined by the NCSA HDF5 library. Values 256 through 511 have been set + aside for use when developing/testing new filters. The remaining values are allocated to specific + filters by contacting the HDF5 development team.
Name LengthEach filter has an optional null-terminated ASCII name and this field holds the length of the name + including the null termination padded with nulls to be a multiple of eight. If the filter has no name + then a value of zero is stored in this field.
FlagsThe flags indicate certain properties for a filter. The bit values defined so far are: +
+
bit 1
+
If set then the filter is an optional filter. During output, if an optional filter fails it will + be silently removed from the pipeline.
+
Client Data Number of ValuesEach filter can store a few integer values to control how the filter operates. The number of entries + in the Client Data array is stored in this field.
NameIf the Name Length field is non-zero then it will contain the size of this field, a multiple of eight. + This field contains a null-terminated, ASCII character string to serve as a comment/name for the filter.
Client DataThis is an array of four-byte integers which will be passed to the filter function. The Client Data + Number of Values determines the number of elements in the array.
PaddingFour bytes of zeros are added to the message at this point if the Client Data Number of Values field + contains an odd number.
+ +\subsubsection subsubsec_fmt1_dataobject_hdr_attribute Name: Attribute +Type: 0x000C
+Length: varies
+Status: Optional, may be repeated.
+ +Purpose and Description: The Attribute message is used to list objects in the HDF +file which are used as attributes, or "meta-data" about the current object. An attribute is a small dataset; +it has a name, a datatype, a data space, and raw data. Since attributes are stored in the object header they +must be relatively small (<64kb) and can be associated with any type of object which has an object header +(groups, datasets, named types and spaces, etc.). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Attribute Message
bytebytebytebyte
VersionReservedName Size
Type SizeSpace Size

Name


Type


Space


Data

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionVersion number for the message. This document describes version 1 of attribute messages.
ReservedThis field is reserved for later use and is set to zero.
Name SizeThe length of the attribute name in bytes including the null terminator. Note that the Name field + below may contain additional padding not represented by this field.
Type SizeThe length of the datatype description in the Type field below. Note that the Type field may contain + additional padding not represented by this field.
Space SizeThe length of the dataspace description in the Space field below. Note that the Space field may contain + additional padding not represented by this field.
NameThe null-terminated attribute name. This field is padded with additional null characters to make it a + multiple of eight bytes.
TypeThe datatype description follows the same format as described for the datatype object header message. + This field is padded with additional zero bytes to make it a multiple of eight bytes.
SpaceThe dataspace description follows the same format as described for the dataspace object header message. + This field is padded with additional zero bytes to make it a multiple of eight bytes.
DataThe raw data for the attribute. The size is determined from the datatype and dataspace descriptions. + This field is not padded with additional zero bytes.
+ +\subsubsection subsubsec_fmt1_dataobject_hdr_name Name: Object Name +Type: 0x000D
+Length: varies
+Status: Optional, may not be repeated. + +Purpose and Description: The object name or comment is designed to be a short description +of an object. An object name is a sequence of non-zero (\0) ASCII characters with no other +formatting included by the library. + + + + + + + + + + + + +
Name Message
bytebytebytebyte

Name
br />
+ + + + + + + + + + +
Field NameDescription
NameA null terminated ASCII character string.
+ +\subsubsection subsubsec_fmt1_dataobject_hdr_modified Name: Object Modification Date & Time +Type: 0x000E
+Length: fixed
+Status: Optional, may not be repeated. + +Purpose and Description: The object modification date and time is a timestamp which +indicates (using ISO-8601 date and time format) the last modification of an object. The time is + updated when any object header message changes according to the system clock where the change was posted. + + + + + + + + + + + + + + + + + + + + + + + + +
Modification Time Message
bytebytebytebyte
Year
MonthDay of Month
HourMinute
SecondReserved
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
YearThe four-digit year as an ASCII string. For example, 1998. All fields of this message + should be interpreted as coordinated universal time (UTC)
MonthThe month number as a two digit ASCII string where January is 01 and December is + 12.
Day of MonthThe day number within the month as a two digit ASCII string. The first day of the month is + 01.
HourThe hour of the day as a two digit ASCII string where midnight is 00 and 11:00pm + is 23.
MinuteThe minute of the hour as a two digit ASCII string where the first minute of the hour is + 00 and the last is 59.
SecondThe second of the minute as a two digit ASCII string where the first second of the minute is + 00 and the last is 59.
ReservedThis field is reserved and should always be zero.
+ +\subsubsection subsubsec_fmt1_dataobject_hdr_shared Name: Shared Object Message +Type: 0x000F
+Length: 4 Bytes
+Status: Optional, may be repeated. + +A constant message can be shared among several object headers by writing that message in the global +heap and having the object headers all point to it. The pointing is accomplished with a Shared Object +message which is understood directly by the object header layer of the library. It is also possible to +have a message of one object header point to a message in some other object header, but care must be +exercised to prevent cycles. + +If a message is shared, then the message appears in the global heap and its message ID appears in the +Header Message Type field of the object header. Also, the Flags field in the object header for that +message will have bit two set (the H5O_FLAG_SHARED bit). The message body in the object +header will be that of a Shared Object message defined here and not that of the pointed-to message. + + + + + + + + + + + + + + + + +
Shared Message Message
byte + byte + byte + byte +
VersionFlagsReserved
Reserved

Pointer

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number for the message. This document describes version one of shared messages.
FlagsThe Shared Message message points to a message which is shared among multiple object headers. The + Flags field describes the type of sharing: +
+
Bit 0
+
If this bit is clear then the actual message is the first message in some other object header; + otherwise the actual message is stored in the global heap.
+
Bits 2-7
+
Reserved (always zero)
+
PointerThis field points to the actual message. The format of the pointer depends on the value of the Flags + field. If the actual message is in the global heap then the pointer is the file address of the global + heap collection that holds the message, and a four-byte index into that collection. Otherwise the + pointer is a group entry that points to some other object header.
+ +\subsubsection subsubsec_fmt1_dataobject_hdr_continuation Name: Object Header Continuation +Type: 0x0010
+Length: fixed
+Status: Optional, may be repeated.
+Purpose and Description: The object header continuation is the location in the file of more +header messages for the current data object. This can be used when header blocks are large, or likely to +change over time.
+Format of Data: The object header continuation is formatted as follows (assuming a 4-byte +length & offset are being used in the current file): + + + + + + + + + + + + + + +
HDF5 Object Header Continuation Message Layout
bytebytebytebyte
Header Continuation Offset
Header Continuation Length
+ +
+
The elements of the Header Continuation Message are described below:
+
+
+
Header Continuation Offset: (<offset> bytes)
+
This value is the offset in bytes from the beginning of the file where the header continuation + information is located.
+
Header Continuation Length: (<length> bytes)
+
This value is the length in bytes of the header continuation information in the file.
+
+
+ +\subsubsection subsubsec_fmt1_dataobject_hdr_stmgroup Name: Group Message +Type: 0x0011
+Length: fixed
+Status: Required for groups, may not be repeated.
+Purpose and Description: Each group has a B-tree and a name heap which are pointed to +by this message.
+Format of data: + +The group message is formatted as follows: + + + + + + + + + + + + + + +
HDF5 Object Header Group Message Layout
bytebytebytebyte
B-tree Address
Heap Address
+ +
+
The elements of the Group Message are described below:
+
+
+
B-tree Address (<offset> bytes)
+
This value is the offset in bytes from the beginning of the file where the B-tree is located.
+
Heap Address (<offset> bytes)
+
This value is the offset in bytes from the beginning of the file where the group name heap + is located.
+
+
+ +\subsection subsec_fmt1_dataobject_sharedhdr Disk Format: Level 2b - Shared Data Object Headers +In order to share header messages between several dataset objects, object header messages may be placed +into the global heap. Since these messages require additional information beyond the basic object header +message information, the format of the shared message is detailed below. + + + + + + + + + + + + + + + +
HDF5 Shared Object Header Message
bytebytebytebyte
Reference Count of Shared Header Message

Shared Object Header Message

+ +
+
The elements of the shared object header message are described below:
+
+
+
Reference Count of Shared Header Message: (32-bit unsigned integer)
+
This value is used to keep a count of the number of dataset objects which refer to this message + from their dataset headers. When this count reaches zero, the shared message header may be + removed from the global heap.
+
Shared Object Header Message: (various lengths)
+
The data stored for the shared object header message is formatted in the same way as the private + object header messages described in the object header description earlier in this document and + begins with the header message Type.
+
+
+ +\subsection subsec_fmt1_dataobject_storage Disk Format: Level 2c - Data Object Data Storage +The data for an object is stored separately from the header information in the file and may not actually +be located in the HDF5 file itself if the header indicates that the data is stored externally. The +information for each record in the object is stored according to the dimensionality of the object +(indicated in the dimensionality header message). Multi-dimensional data is stored in C order [same +as current scheme], i.e. the "last" dimension changes fastest. + +Data whose elements are composed of simple number-types are stored in native-endian IEEE format, unless +they are specifically defined as being stored in a different machine format with the architecture-type +information from the number-type header message. This means that each architecture will need to +[potentially] byte-swap data values into the internal representation for that particular machine. + +Data with a "variable" sized number-type is stored in a data heap internal to the HDF5 file. Global heap +identifiers are stored in the data object storage. + +Data whose elements are composed of pointer number-types are stored in several different ways depending +on the particular pointer type involved. Simple pointers are just stored as the dataset offset of the +object being pointed to with the size of the pointer being the same number of bytes as offsets in the file. +Partial-object pointers are stored as a heap-ID which points to the following information within the +file-heap: an offset of the object pointed to, number-type information (same format as header message), +dimensionality information (same format as header message), sub-set start and end information (i.e. a +coordinate location for each), and field start and end names (i.e. a [pointer to the] string indicating +the first field included and a [pointer to the] string name for the last field). + +Data of a compound datatype is stored as a contiguous stream of the items in the structure, with each +item formatted according to its datatype. + +*/ diff --git a/doxygen/dox/H5.format.1.1.dox b/doxygen/dox/H5.format.1.1.dox new file mode 100644 index 00000000000..e120c35c3ab --- /dev/null +++ b/doxygen/dox/H5.format.1.1.dox @@ -0,0 +1,3887 @@ + +/** \page FMT11 HDF5 File Format Specification Version 1.1 +
    +
  1. @ref sec_fmt11_intro
    2. +
  2. @ref sec_fmt11_meta +
      +
    1. @ref subsec_fmt11_boot_super
      2. +
    2. @ref subsec_fmt11_boot_driver
      3. +
    3. +
  3. @ref sec_fmt11_infra +
      +
    1. @ref subsec_fmt11_infra_btrees
      2. +
    2. @ref subsec_fmt11_infra_symboltable
      3. +
    3. @ref subsec_fmt11_infra_symboltableentry
      4. +
    4. @ref subsec_fmt11_infra_localheap
      5. +
    5. @ref subsec_fmt11_infra_globalheap
      6. +
    6. @ref subsec_fmt11_infra_freespaceindex
      7. +
    4. +
  4. @ref sec_fmt11_dataobject +
      +
    1. @ref subsec_fmt11_dataobject_hdr +
        +
      1. @ref subsubsec_fmt11_dataobject_hdr_nil
        2. +
      2. @ref subsubsec_fmt11_dataobject_hdr_simple
        3. +
      3. @ref subsubsec_fmt11_dataobject_hdr_message_0002
        4. +
      4. @ref subsubsec_fmt11_dataobject_hdr_dtmessage
        5. +
      5. @ref subsubsec_fmt11_dataobject_hdr_ofvmessage
        6. +
      6. @ref subsubsec_fmt11_dataobject_hdr_fvmessage
        7. +
      7. @ref subsubsec_fmt11_dataobject_hdr_message_0006
        8. +
      8. @ref subsubsec_fmt11_dataobject_hdr_external
        9. +
      9. @ref subsubsec_fmt11_dataobject_hdr_layout
        10. +
      10. @ref subsubsec_fmt11_dataobject_hdr_message_0009
        11. +
      11. @ref subsubsec_fmt11_dataobject_hdr_message_000A
        12. +
      12. @ref subsubsec_fmt11_dataobject_hdr_filter
        13. +
      13. @ref subsubsec_fmt11_dataobject_hdr_attribute
        14. +
      14. @ref subsubsec_fmt11_dataobject_hdr_comment
        15. +
      15. @ref subsubsec_fmt11_dataobject_hdr_modified
        16. +
      16. @ref subsubsec_fmt11_dataobject_hdr_shared
        17. +
      17. @ref subsubsec_fmt11_dataobject_hdr_continuation
        18. +
      18. @ref subsubsec_fmt11_dataobject_hdr_stmgroup
        19. +
      19. @ref subsubsec_fmt11_dataobject_hdr_mod
        20. +
      2. +
    2. @ref subsec_fmt11_dataobject_storage
      3. +
    +
    5. +
  5. @ref sec_fmt11_appendix +
+ + + +\section sec_fmt11_intro Introduction + + + + + + + + + + + + + + +
Figure 1: Relationships among the HDF5 root group, other groups, and objects
\image html FF-IH_FileGroup.gif
Figure 2: HDF5 objects -- datasets, datatypes, or dataspaces
\image html FF-IH_FileObject.gif
+ +The format of an HDF5 file on disk encompasses several key ideas of the HDF4 and AIO file formats as well +as addressing some shortcomings therein. The new format is more self-describing than the HDF4 format and +is more uniformly applied to data objects in the file. + +An HDF5 file appears to the user as a directed graph. The nodes of this graph are the higher-level HDF5 +objects that are exposed by the HDF5 APIs: +\li Groups +\li Datasets +\li Named datatypes + +At the lowest level, as information is actually written to the disk, an HDF5 file is made up of the +following objects: +\li A super block +\li B-tree nodes (containing either symbol nodes or raw data chunks) +\li Object headers +\li A global heap +\li Local heaps +\li Free space + +The HDF5 library uses these lower-level objects to represent the higher-level objects that are then +presented to the user or to applications through the APIs. For instance, a group is an object header that +contains a message that points to a local heap and to a B-tree which points to symbol nodes. A dataset is +an object header that contains messages that describe datatype, space, layout, filters, external files, +fill value, etc with the layout message pointing to either a raw data chunk or to a B-tree that points to +raw data chunks. + +\subsection subsec_fmt11_intro_doc This Document +This document describes the lower-level data objects; the higher-level objects and their properties are +described in the \ref UG. + +Three levels of information comprise the file format. Level 0 contains basic information for identifying +and defining information about the file. Level 1 information contains the information about the pieces of a +file shared by many objects in the file (such as a B-trees and heaps). Level 2 is the rest of the file and +contains all of the data objects, with each object partitioned into header information, also known as +metadata, and data. + +The sizes of various fields in the following layout tables are determined by looking at the number of +columns the field spans in the table. There are three exceptions: (1) The size may be overridden by +specifying a size in parentheses, (2) the size of addresses is determined by the Size of Offsets +field in the super block and is indicated in this document with a superscripted 'O', and (3) the size of +length fields is determined by the Size of Lengths field in the super block and is indicated +in this document with a superscripted 'L'. + +Values for all fields in this document should be treated as unsigned integers, unless otherwise noted in +the description of a field. Additionally, all metadata fields are stored in little-endian byte order. + +\section sec_fmt11_meta Disk Format: Level 0 - File Metadata + +\subsection subsec_fmt11_boot_super Disk Format: Level 0A - File Signature and Super Block +The super block may begin at certain predefined offsets within the HDF5 file, allowing a block of +unspecified content for users to place additional information at the beginning (and end) of the HDF5 file +without limiting the HDF5 library's ability to manage the objects within the file itself. This feature was +designed to accommodate wrapping an HDF5 file in another file format or adding descriptive information to +the file without requiring the modification of the actual file's information. The super block is located by +searching for the HDF5 file signature at byte offset 0, byte offset 512 and at successive locations in the +file, each a multiple of two of the previous location, i.e. 0, 512, 1024, 2048, etc. + +The super block is composed of a file signature, followed by super block and group version numbers, +information about the sizes of offset and length values used to describe items within the file, the size of +each group page, and a group entry for the root object in the file. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
HDF5 Super Block Layout
bytebytebytebyte

HDF5 File Signature (8 bytes)

Version \# of Super BlockVersion \# of Global Free-space StorageVersion \# of Root Group Symbol Table EntryReserved (zero)
Version \# of Shared Header Message FormatSize of OffsetsSize of LengthsReserved (zero)
Group Leaf Node KGroup Internal Node K
File Consistency Flags
Indexed Storage Internal Node K1Reserved (zero)1
Base AddressO
Address of Global Free-space HeapO
End of File AddressO
Driver Information Block AddressO
Root Group Symbol Table Entry
+\li Items marked with an 'O' in the above table are of the size specified in "Size of Offsets." +\li Items marked with an '1' in the above table are new in version 1 of the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
HDF5 File SignatureThis 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: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Decimal:13772687013102610
Hexadecimal:894844460d0a1a0a
ASCII C Notation:\211HDF\\r\\n\032\\n
+
+ 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 Super BlockThis value is used to determine the format of the information in the super block. When the format of + the information in the super block is changed, the version number is incremented to the next integer + and can be used to determine how the information in the super block is formatted.
+ Values of 0 and 1 are defined for this field.
+ This field is present in version 0+ of the superblock.
Version Number of the File Free-space HeapThis value is used to determine the format of the information in the File Free-space Heap.
+ The only value currently valid in this field is '0', which indicates that the free space index is + formatted as described in the @ref subsec_fmt11_infra_freespaceindex below.
+ This field is present in version 0+ of the superblock.
Version Number of the Root Group Symbol Table EntryThis value is used to determine the format of the information in the Group. When 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 in the @ref subsec_fmt11_infra_symboltableentry below.
+ This field is present in version 0+ of the superblock.
Version Number of the Shared Header Message FormatThis value is used to determine the format of the information in a shared object header message, which + is stored in the global small-data heap. 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 in the @ref subsubsec_fmt11_dataobject_hdr_shared below.
+ This field is present in version 0+ of the superblock.
Size of OffsetsThis 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 + super block 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 LengthsThis 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 KEach 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 @ref subsec_fmt11_infra_btrees below.
+ This field is present in version 0+ of the superblock.
Group Internal Node KEach 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 @ref subsec_fmt11_infra_btrees below.
+ This field is present in version 0+ of the superblock.
File Consistency FlagsThis value contains flags to indicate information about the consistency of the information contained + within the file. Currently, the following bit flags are defined: +
    +
  • Bit 0 set indicates that the file is opened for write-access.
    • +
  • Bit 1 set indicates that the file has been verified for consistency and is guaranteed to be + consistent with the format defined in this document.
    • +
  • Bits 2-31 are reserved for future use.
    • +
+ Bit 0 should be set as the first action when a file is opened for write access and should be cleared + only as the final action when closing a file. Bit 1 should be cleared during normal access to a file + and only set after the file's consistency is guaranteed by the library or a consistency utility.
+ This field is present in version 0+ of the superblock.
Indexed Storage Internal Node KEach internal node of a indexed storage 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 @ref subsec_fmt11_infra_btrees below.
+ This field is present in version 1+ of the superblock.
Base AddressThis 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 super block 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 IndexFree-space management is not yet defined in the HDF5 file format and is not handled by the library. + Currently this field always contains the undefined address.
+ This field is present in version 0+ of the superblock.
End of File AddressThis is the relative file address of the first byte past the end of all HDF5 data. It is used to + determine whether a file has been accidentally truncated and as an address where file data allocation + can occur if the free list is not used.
+ This field is present in version 0+ of the superblock.
Driver Information Block AddressThis 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+ of the superblock.
Root Group Symbol Table EntryThis is the @ref subsec_fmt11_infra_symboltableentry of the root group, which serves as the entry-point + into the group graph for the file.
+ This field is present in version 0+ of the superblock.
+ +\subsection subsec_fmt11_boot_driver Disk Format: Level 0B - File Driver Info +The file driver information block is an optional region of the file which contains information +needed by the file driver in order to reopen a file. The format of the file driver information block is: + + + + + + + + + + + + + + + + + + + + + +
Driver Information Block
bytebytebytebyte
VersionReserved (zero)
Driver Information Size (4 bytes)

Driver Identification (8 bytes)



Driver Information (n bytes)


+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number of the driver information block. The file format documented here is version zero.
Driver Information SizeThe size in bytes of the Driver Information part of this structure.
Driver IdentificationThis is an eight-byte ASCII string without null termination which identifies the driver and version number + of the Driver Information block. The predefined drivers supplied with the HDF5 library are 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.
+ For example, the various versions of the multi driver will be identified by + NCSAmult. (NCSAmult is simply NCSAmulti truncated to eight characters. + Subsequent identifiers will be created by substituting sequential numerical values for the final character, + starting with zero.) multi driver is the only default driver that is encoded in this field.
+ Identification for user-defined drivers is eight-byte long and arbitrary but should be unique and avoid + the four character prefix "NCSA".
Driver InformationDriver information is encoded/decoded in a format defined by the file driver, multi driver is + the only default driver that has driver information stored in this field. Its format is explained in the + following block.
+ +Multi driver has the following format: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Multi Driver Message
bytebytebytebyte
Member MappingMember MappingMember MappingMember Mapping
Member MappingMember MappingReservedReserved

Address of Member File 1


End of Address for Member File 1


Address of Member File 2


End of Address for Member File 2


... ...


Name of Member File 1


Name of Member File 2


... ...

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Member MappingMulti driver enables different types of HDF5 data and metadata to be written to separate + files. These files are viewed by the library as a single virtual HDF5 file with a single file address. + It allows maximal 6 files to be created. In sequence, these Member Mapping fields are for + super block, B-tree, raw data, global heap, local heap, and object header. More than one type of data + can be written to the same file.
+ These Member Mapping fields are integer values from 1 to 6 indicating how the data can be + mapped to or merged with another type of data. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Member MappingDescription
1The super block data.
2The B-tree data.
3The raw data.
4The global heap data.
5The local heap data.
6The 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, one for super block, + B-tree, global heap, local heap, and object header.
ReservedThese fields are reserved and should always be zero.
Address of Member FileSpecifies the virtual address. A normally eight-byte integer with the value from 0 + (zero) to maximal value, at which the member file starts.
End of Address for Member FileThe end of allocated address for the member file. A normally eight-byte integer value.
Name of Member FileThe null-terminated name of member file. 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 super block), + b (for B-tree), r (for raw data), g (for global heap), + l (for local heap), and o (for object header). The name for the whole + HDF5 file will substitute the %s in the string.
+ +\section sec_fmt11_infra Disk Format: Level 1 - File Infrastructure + +\subsection subsec_fmt11_infra_btrees Disk Format: Level 1A - B-link Trees and B-tree Nodes +B-link trees allow flexible storage for objects which tend to grow in ways that cause the object to be stored +discontiguously. B-trees are described in various algorithms books including "Introduction to Algorithms" by +Thomas H. Cormen, Charles E. Leiserson, and Ronald L. Rivest. The B-link tree, in which the sibling nodes at +a particular level in the tree are stored in a doubly-linked list, is described in the "Efficient Locking +for Concurrent Operations on B-trees" paper by Phillip Lehman and S. Bing Yao as published in the ACM +Transactions on Database Systems, Vol. 6, No. 4, December 1981. + +The B-link trees implemented by the file format contain one more key than the number of children. In other +words, each child pointer out of a B-tree node has a left key and a right key. The pointers out of internal +nodes point to sub-trees while the pointers out of leaf nodes point to symbol nodes and raw data chunks. +Aside from that difference, internal nodes and leaf nodes are identical. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
B-tree Nodes
bytebytebytebyte
Node Signature
Node TypeNode LevelEntries Used
Address of Left SiblingO
Address of Right SiblingO
Key 0 (variable size)
Address of Child 0O
Key 1 (variable size)
Address of Child 1O
...
Key 2K (variable size)
Address of Child 2KO
Key 2K+1 (variable size)
+ + + + + +
(Items marked with an 'O' the above table are of the size specified in "Size of Offsets.")
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe ASCII character string TREE is used to indicate the beginning of a B-link tree node. + This gives file consistency checking utilities a better chance of reconstructing a damaged file.
Node TypeEach B-link 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 TypeDescription
0This tree points to group nodes.1This tree points to a raw data chunk.
+
Node LevelThe 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 UsedThis 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 SiblingThis 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 SiblingThis 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 PointersEach 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-link tree contains N child pointers and + N+1 keys.
KeyThe 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, the key is formatted as follows: + + + + + +
A single field of Size of Lengths bytesIndicates 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, the key is formatted as follows: + + + + + + + + + + + + + +
Bytes 1-4Size of chunk in bytes.
Bytes 4-8Filter mask, a 32-bit bitfield 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 it's index is set.
N 64-bit fieldsA 64-bit index indicating the offset of the chunk within the dataset where N is the number + of dimensions of the dataset. For example, if a chunk in a 3-dimensional dataset begins at the + position [5,5,5], there will be three such 64-bit indices, each with the value of + 5.
+
Child PointerThe 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 chunk 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 @ref subsec_fmt11_infra_symboltableentry, which contains + information for multiple symbol table entries.
+ +Conceptually, each B-tree node looks like this: + + + + + + + + + + + + + +
key[0] child[0] key[1] child[1] key[2]; ... ... key[N-1] child[N-1] key[N]
+where child[i] is a pointer to a sub-tree (at a level above Level 0) or to data (at Level 0). +Each key[i] describes an item stored by the B-tree (a chunk or an object of a group node). +The range of values represented by child[i] is indicated by key[i] and key[i+1]. + +The following question must next be answered: "Is the value described by key[i] contained in +child[i-1] or in child[i]?" The answer depends on the type of tree. In trees for groups (node +type 0) the object described by key[i] is the greatest object contained in child[i-1] while +in chunk trees (node type 1) the chunk described by key[i] is the least chunk in child[i]. + +That means that key[0] for group trees is sometimes unused; it points to offset zero in the heap, which is +always the empty string and compares as "less-than" any valid object name. + +And key[N] for chunk trees is sometimes unused; it contains a chunk offset which compares as +"greater-than" any other chunk offset and has a chunk byte size of zero to indicate that it is not actually +allocated. + +\subsection subsec_fmt11_infra_symboltable Disk Format: Level 1B - Group and Symbol Nodes +A group is an object internal to the file that allows arbitrary nesting of objects within the file (including +other groups). A group maps a set of names in the group to a set of relative file addresses where objects with +those names are located in the file. Certain metadata for an object to which the group points can be cached in +the group's symbol table in addition to the object's header. + +An HDF5 object name space can be stored hierarchically by partitioning the name into components and storing +each component in a group. The group entry for a non-ultimate component points to the group containing the +next component. The group entry for the last component points to the object being named. + +A group is a collection of group nodes pointed to by a B-link tree. Each group node contains entries for one +or more symbols. If an attempt is made to add a symbol to an already full group node containing 2K +entries, then the node is split and one node contains K symbols and the other contains K+1 +symbols. + + + + + + + + + + + + + + + + + + + + +
Group Node (A Leaf of a B-tree)
bytebytebytebyte
Signature
Version NumberReserved (0)Number of Symbols


Group Entries


+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe ASCII character string SNOD is used to indicate the beginning of a group node. This + gives file consistency checking utilities a better chance of reconstructing a damaged file.
Version NumberThe version number for the group node. This document describes version 1. (There is no version '0' + of the group node)
Number of SymbolsAlthough all group nodes have the same length, most contain fewer than the maximum possible number of + symbol entries. This field indicates how many entries contain valid data. The valid entries are packed + at the beginning of the group node while the remaining entries contain undefined values.
Group EntriesEach symbol has an entry in the group 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 + @ref subsec_fmt11_boot_super.
+ +\subsection subsec_fmt11_infra_symboltableentry Disk Format: Level 1C - Group Entry +Each group entry in a group node is designed to allow for very fast browsing of stored objects. Toward that +design goal, the group entries include space for caching certain constant metadata from the object header. + + + + + + + + + + + + + + + + + + + + + + + + +
Group Entry
bytebytebytebyte
Name OffsetO
Object Header AddressO
Cache Type
Reserved


Scratch-pad Space (16 bytes)


+ + + + + +
(Items marked with an 'O' the above table are of the size specified in "Size of Offsets.")
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Name OffsetThis is the byte offset into the group local heap for the name of the object. The name is null + terminated.
Object Header AddressEvery 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 metadata can be cached in the scratch-pad space.
Cache TypeThe cache type is determined from the object header. It also determines the format for the scratch-pad + space.
+ + + + + + + + + + + + + + + + + + + + + +
Type:Description:
0No 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.
1Object header metadata is cached in the group entry. This implies that the group entry refers to + another group.
2The 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.
NOther cache values can be defined later and libraries that do not understand the new values will + still work properly.
+
ReservedThese 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 SpaceThis space is used for different purposes, depending on the value of the Cache Type field. Any meta-data + about a dataset object represented in the scratch-pad space is duplicated in the object header for + that dataset. This metadata can include the datatype and the size of the dataspace for a dataset whose + datatype is atomic and whose dataspace is fixed and less than four dimensions.
+ Furthermore, no data is cached in the group entry scratch-pad space if the object header for the group + entry has a link count greater than one.
+ +\subsubsection subsubsec_fmt11_infra_symboltableentry_scratch Format of the Scratch-pad Space +The group entry scratch-pad space is formatted according to the value in the Cache Type field. + +If the Cache Type field contains the value zero ((0)) then no information is stored in the +scratch-pad space. + +If the Cache Type field contains the value one (1), then the scratch-pad space contains +cached metadata for another object header in the following format: + + + + + + + + + + + + + +
Object Header Scratch-pad Format
bytebytebytebyte
Address of B-treeO
Address of Name HeapO
+ + + + + +
(Items marked with an 'O' the above table are of the size specified in "Size of Offsets.")
+ + + + + + + + + + + + + + +
Field NameDescription
Address of B-treeThis is the file address for the root of the group's B-tree.
Address of Name HeapThis is the file address for the group's local heap, in which are stored the symbol names.
+ +If the Cache Type field contains the value two ((2)), then the scratch-pad space contains +cached metadata for another symbolic link in the following format: + + + + + + + + + + + +
Symbolic Link Scratch-pad Format
bytebytebytebyte
Offset to Link Value
+ + + + + + + + + + +
Field NameDescription
Offset to Link ValueThe 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.
+ +\subsection subsec_fmt11_infra_localheap Disk Format: Level 1D - Local Heaps +A heap is a collection of small heap objects. Objects can be inserted and removed from the heap at any time. +The address of a heap does not change once the heap is created. References to objects are stored in the group +table; the names of those objects are stored in the local heap. + + + + + + + + + + + + + + + + + + + + + + + + +
Local Heap
bytebytebytebyte
Signature
VersionReserved (zero)
Data Segment SizeL
Offset to Head of Free-listL
Address of Data SegmentO
+ + + + + + + + +
(Items marked with an 'L' the above table are of the size specified in "Size of Lengths.")
(Items marked with an 'O' the above table are of the size specified in "Size of Offsets.")
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe 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.
VersionEach 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 SizeThe total amount of disk memory allocated for the heap data. This may be larger than the amount of space + required by the object stored in the heap. The extra unused space holds a linked list of free blocks.
Offset to Head of Free-listThis is the offset within the heap data segment of the first free block (or the + undefined address if there is no 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 of the current + block, making the minimum size of a free block 2 * "Size of Lengths".
Address of Data SegmentThe 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.
+ +Objects within the heap should be aligned on an 8-byte boundary. + +\subsection subsec_fmt11_infra_globalheap Disk Format: Level 1E - Global Heap +Each HDF5 file has a global heap which stores various types of information which is typically shared between +datasets. The global heap was designed to satisfy these goals: +
    +
  1. Repeated access to a heap object must be efficient without resulting in repeated file I/O requests. + Since global heap objects will typically be shared among several datasets, it is probable that the + object will be accessed repeatedly.
    2. +
  2. Collections of related global heap objects should result in fewer and larger I/O requests. For + instance, a dataset of object references will have a global heap object for each reference. Reading + the entire set of object references should result in a few large I/O requests instead of one small + I/O request for each reference.
    3. +
  3. It should be possible to remove objects from the global heap and the resulting file hole should be + eligible to be reclaimed for other uses.
    4. +
+ +The implementation of the heap makes use of the memory management already available at the file level and +combines that with a new top-level object called a collection to achieve Goal B. The global heap is +the set of all collections. Each global heap object belongs to exactly one collection and each collection +contains one or more global heap objects. For the purposes of disk I/O and caching, a collection is treated +as an atomic object. + +The HDF5 library creates global heap collections as needed, so there may be multiple collections throughout +the file. The set of all of them is abstractly called the "global heap", although they don't actually link +to each other, and there is no global place in the file where you can discover all of the collections. The +collections are found simply by finding a reference to one through another object in the file (eg. +variable-length datatype elements, etc). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
A Global Heap Collection
bytebytebytebyte
Signature
VersionReserved
Collection SizeL

Global Heap Object 1


Global Heap Object 2


...


Global Heap Object N


Global Heap Object 0 (free space)

+ + + + + +
(Items marked with an 'L' the above table are of the size specified in "Size of Lengths.")
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe 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.
VersionEach 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 SizeThis 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 NThe objects are stored in any order with no intervening unused space.
Global Heap Object 0Global 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 the collection contains no free space.
+ + + + + + + + + + + + + + + + + + + + + + +
Global Heap Object
bytebytebytebyte
Heap Object IDReference Count
Reserved
Object SizeL

Object Data

+ + + + + +
(Items marked with an 'L' the above table are of the size specified in "Size of Lengths.")
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Heap Object IDEach 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 CountAll 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.
ReservedZero 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 DataThe object data is treated as a one-dimensional array of bytes to be interpreted by the caller.
+ +\subsection subsec_fmt11_infra_freespaceindex Disk Format: Level 1F - Free-space Index +The free-space index is a collection of blocks of data, dispersed throughout the file, which are currently +not used by any file objects. + +The super block contains a pointer to root of the free-space description; that pointer is currently required +to be the undefined address. + +The format of the free-space index is not defined at this time. + +\section sec_fmt11_dataobject Disk Format: Level 2 - Data Objects +Data objects contain the real information in the file. These objects compose the scientific data and other +information which are generally thought of as "data" by the end-user. All the other information in the file +is provided as a framework for these data objects. + +A data object is composed of header information and data information. The header information contains the +information needed to interpret the data information for the data object as well as additional "meta-data" +or pointers to additional "meta-data" used to describe or annotate each data object. + +\subsection subsec_fmt11_dataobject_hdr Disk Format: Level 2A - Data Object Headers +The header information of an object is designed to encompass all the information about an object, except for +the data itself. This information includes the dataspace, datatype, information about how the data is stored +on disk (in external files, compressed, broken up in blocks, etc.), as well as other information used by the +library to speed up access to the data objects or maintain a file's integrity. Information stored by user +applications as attributes is also stored in the object's header. The header of each object is not necessarily +located immediately prior to the object's data in the file and in fact may be located in any position in the +file. The order of the messages in an object header is not significant. + +Header messages are aligned on 8-byte boundaries. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Object Headers
bytebytebytebyte
VersionReserved (zero)Number of Header Messages
Object Reference Count
Object Header Size
Header Message Type \#1Size of Header Message Data \#1
Header Message \#1 FlagsReserved (zero)

Header Message Data \#1

.
.
.
Header Message Type \#nSize of Header Message Data \#n
Header Message \#n FlagsReserved (zero)

Header Message Data \#n

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThis value is used to determine the format of the information in the object header. When the format of + the information in 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 document describes version one + (1) (there was no version zero (0)).
Number of Header MessagesThis value determines the number of messages listed in object headers for this object. This value + includes the messages in continuation messages for this object.
Object Reference CountThis 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 SizeThis value specifies the total 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 TypeThis value specifies the type of information included in the following header message data. The header + message types for the pre-defined header messages are included in sections below.
Size of Header Message DataThis 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 FlagsThis is a bit field with the following definition: + + + + + + + + + + + + + + + + + +
BitDescription
0If set, the message data is constant. This is used for messages like the datatype message of + a dataset.
1If set, the message is stored in the global heap. The Header Message Data field contains a + Shared Object message and the Size of Header Message Data field contains the size of that + Shared Object message.
2-7Reserved
+
Header Message DataThe 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 zeros to make the size a multiple of + eight.
+ +The header message types and the message data associated with them compose the critical "meta-data" about +each object. Some header messages are required for each object while others are optional. Some optional +header messages may also be repeated several times in the header itself, the requirements and number of +times allowed in the header will be noted in each header message description below. + +The following is a list of currently defined header messages: + +\subsubsection subsubsec_fmt11_dataobject_hdr_nil Name: NIL +Header Message Type: 0x0000 + +Length: varies + +Status: Optional, may be repeated. + +Purpose and Description: The NIL message is used to indicate a message which is to be ignored +when reading the header messages for a data object. [Possibly one which has been deleted for some reason.] + +Format of Data: Unspecified.
+ +\subsubsection subsubsec_fmt11_dataobject_hdr_simple Name: Simple Dataspace +Header Message Type: 0x0001 + +Length: Varies according to the number of dimensions, as described in the following table + +Status: Required for dataset objects, may not be repeated. + +Description:The simple dataspace message describes the number of dimensions (i.e. "rank") +and size of each dimension that the data object has. This message is only used for datasets which have a +simple, rectilinear grid layout; datasets requiring a more complex layout (irregularly structured or +unstructured grids, etc.) must use the Complex Dataspace message for expressing the space the +dataset inhabits. (Note: The Complex Dataspace functionality is not yet implemented (and it is +not described in this document.) + +Format of Data:
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Simple Dataspace Message
bytebytebytebyte
VersionDimensionalityFlagsReserved
Reserved
Dimension \#1 SizeL
.
.
.
Dimension \#n SizeL
Dimension \#1 Maximum SizeL
.
.
.
Dimension \#n Maximum SizeL
Permutation Index \#1L
.
.
.
Permutation Index \#nL
+ + + + + +
(Items marked with an 'L' the above table are of the size specified in "Size of Lengths.")
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Version This value is used to determine the format of the Simple 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)).
DimensionalityThis value is the number of dimensions that the data object has.
FlagsThis 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 SizeThis 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 SizeThis 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 \#nThis 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.
+ +\subsubsection subsubsec_fmt11_dataobject_hdr_message_0002 Name: Reserved - Not Assigned Yet +Header Message Type: 0x0002
+Length: N/A
+Status: N/A
+Format of Data: N/A
+Purpose and Description: This message type was skipped during the initial specification +of the file format and may be used in a future expansion to the format. + +\subsubsection subsubsec_fmt11_dataobject_hdr_dtmessage Name: Datatype +Header Message Type: 0x0003
+Length: variable
+Status: Required for dataset or named datatype objects, may not be repeated.
+ +Description: The datatype message defines the datatype for each element of a dataset. A +datatype can describe an atomic type like a fixed- or floating-point type or a compound type like a C +struct. Datatypes are stored as a list of datatype classes and their associated properties. + +Datatype messages that are part of a dataset object, do not describe how elements are related to one +another, the dataspace message is used for that purpose. Datatype messages that are part of a named +datatype message describe an "abstract" datatype that can be used by other objects in the file. + +Format of Data:
+ + + + + + + + + + + + + + + + + + + + +
Datatype Message
bytebytebytebyte
Type Class and VersionClass Bit Field, Bits 0-7Class Bit Field, Bits 8-15Class Bit Field, Bits 16-23
Size


Properties

/
+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Class and VersionThe 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: + + + + + + + + + + + + + + + + + +
VersionDescription
0Never used
1Used by early versions of the library to encode compound datatypes with explicit array fields. + See the compound datatype description below for further details.
2The current version used by the library.

+ 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: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0Fixed-Point
1Floating-Point
2Time
3String
4Bitfield
5Opaque
6Compound
7Reference
8Enumerated
9Variable-Length
10Array
+
Class Bit FieldsThe 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.
SizeThe size of the datatype in bytes.
PropertiesThis variable-sized field encodes information specific to each datatype class and is described + below. If there is no property information specified for a datatype class, the size of this field + is zero.
+ +Class specific information for Fixed-Point Numbers (Class 0): + + + + + + + + + + + + + + + + + + + + + + +
Bit Field Description
BitsMeaning
0Byte Order. If zero, byte order is little-endian; otherwise, byte order is big endian.
1, 2Padding type. Bit 1 is the lo_pad type and bit 2 is the hi_pad type. If a datum has + unused bits at either end, then the lo_pad or hi_pad bit is copied to those locations.
3Signed. If this bit is set then the fixed-point number is in 2's complement form.
4-23Reserved (zero).
+ + + + + + + + + + + + + +
+ Property Descriptions +
ByteByteByteByte
Bit OffsetBit Precision
+ + + + + + + + + + + + + + +
Field NameDescription
Bit OffsetThe bit offset of the first significant bit of the fixed-point value within the datatype. The + bit offset specifies the number of bits "to the right of" the value.
Bit PrecisionThe number of bits of precision of the fixed-point value within the datatype.
+ +Class specific information for Floating-Point Numbers (Class 1): + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Bit Field Description
BitsMeaning
0Byte Order. If zero, byte order is little-endian; otherwise, byte order is big endian.
1, 2, 3Padding type. Bit 1 is the low bits pad type, bit 2 is the high bits pad type, and bit + 3 is the internal bits pad type. If a datum has unused bits at either end or between the sign bit, exponent, + or mantissa, then the value of bit 1, 2, or 3 is copied to those locations.
4-5Normalization. The value can be 0 if there is no normalization, 1 if the most significant + bit of the mantissa is always set (except for 0.0), and 2 if the most significant bit of the mantissa is not + stored but is implied to be set. The value 3 is reserved and will not appear in this field.
6-7Reserved (zero).
8-15Sign Location. This is the bit position of the sign bit. Bits are numbered with the least + significant bit zero.
16-23Reserved (zero).
+ + + + + + + + + + + + + + + + + + + + + + +
Property Descriptions
ByteByteByteByte
Bit OffsetBit Precision
Exponent LocationExponent SizeMantissa LocationMantissa Size
Exponent Bias
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameProperty Description
Bit OffsetThe bit offset of the first significant bit of the floating-point value within the datatype. The + bit offset specifies the number of bits "to the right of" the value.
Bit PrecisionThe number of bits of precision of the floating-point value within the datatype.
Exponent LocationThe bit position of the exponent field. Bits are numbered with the least significant + bit number zero.
Exponent SizeThe size of the exponent field in bits.
Mantissa LocationThe bit position of the mantissa field. Bits are numbered with the least significant bit number + zero.
Mantissa SizeThe size of the mantissa field in bits.
Exponent BiasThe bias of the exponent field.
+ +Class specific information for Time (Class 2): + + + + + + + + + + + + + + +
Bit Field Description
BitsMeaning
0Byte Order. If zero, byte order is little-endian; otherwise, byte order is big endian.
1-23Reserved (zero).
+ + + + + + + + + + +
Property Descriptions
ByteByte
Bit Precision
+ + + + + + + + + + +
Field NameDescription
Bit PrecisionThe number of bits of precision of the time value.
+ +Class specific information for Strings (Class 3): + + + + + + + + + + + + + + + + + +
Bit Field Description
BitsMeaning
0-3Padding type. This four-bit value determines the type of padding to use for the + string. The values are: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0Null Terminate: A zero byte marks the end of the string and is guaranteed to be present after + converting a long string to a short string. When converting a short string to a long string the + value is padded with additional null characters as necessary.
1Null Pad: Null characters are added to the end of the value during conversions from short values + to long values but conversion in the opposite direction simply truncates the value.
2Space Pad: Space characters are added to the end of the value during conversions from short values + to long values but conversion in the opposite direction simply truncates the value. This is the + Fortran representation of the string.
3-15Reserved.
+
4-7Character Set. The character set to use for encoding the string. The only character set + supported is the 8-bit ASCII (zero) so no translations have been defined yet.
8-23Reserved (zero).
+ +There are no properties defined for the string class. + +Class specific information for Bitfields (Class 4): + + + + + + + + + + + + + + + + + + +
Bit Field Description
BitsMeaning
0Byte Order. If zero, byte order is little-endian; otherwise, byte order is big endian.
1, 2Padding type. Bit 1 is the lo_pad type and bit 2 is the hi_pad type. If a datum has + unused bits at either end, then the lo_pad or hi_pad bit is copied to those locations.
3-23Reserved (zero).
+ + + + + + + + + + + + + +
Property Description
ByteByteByteByte
Bit OffsetBit Precision
+ + + + + + + + + + + + + + +
Field NameDescription
Bit OffsetThe bit offset of the first significant bit of the bitfield within the datatype. The bit + offset specifies the number of bits "to the right of" the value.
Bit PrecisionThe number of bits of precision of the bitfield within the datatype.
+ +Class specific information for Opaque (Class 5): + + + + + + + + + + + + + + +
Bit Field Description
BitsMeaning
0-7Length of ASCII tag in bytes.
8-23Reserved (zero).
+ + + + + + + + + + + + +
Property Description
ByteByteByteByte

ASCII Tag
+ + + + + + + + + + +
Field NameDescription
ASCII TagThis NUL-terminated string provides a description for the opaque type. It is NUL-padded to a + multiple of 8 bytes.
+ +Class specific information for Compound Types (Class 6): + + + + + + + + + + + + + + +
Bit Field Description
BitsMeaning
0-15Number of Members. This field contains the number of members defined for the + compound datatype. The member definitions are listed in the Properties field of the data type + message.
15-23Reserved (zero).
+ +The Properties field of a compound datatype is a list of the member definitions of the compound datatype. +The member definitions appear one after another with no intervening bytes. The member types are described +with a recursive datatype message. + +Note that the property descriptions are different for different versions of the datatype version. Additionally +note that the version 0 properties are deprecated and have been replaced with the version 1 properties in +versions of the HDF5 library from the 1.4 release onward. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Properties Description for Datatype Version 1
ByteByteByteByte


Name

/
Byte Offset of Member
DimensionalityReserved (zero)
Dimension Permutation
Reserved (zero)
Dimension \#1 Size (required)
Dimension \#2 Size (required)
Dimension \#3 Size (required)
Dimension \#4 Size (required)

Member Type Message

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
NameThis NUL-terminated string provides a description for the opaque type. It is NUL-padded to a + multiple of 8 bytes.
Byte Offset of MemberThis is the byte offset of the member within the datatype.
DimensionalityIf set to zero, this field indicates a scalar member. If set to a value greater than zero, + this field indicates that the member is an array of values. For array members, the size of + the array is indicated by the 'Size of Dimension n' field in this message.
Dimension PermutationThis field was intended to allow an array field to have it's dimensions permuted, but this was + never implemented. This field should always be set to zero.
Dimension \#n SizeThis field is the size of a dimension of the array field 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.
Member Type MessageThis field is a datatype message describing the datatype of the member.
+ + + + + + + + + + + + + + + + + + +
Properties Description for Datatype Version 2
ByteByteByteByte

Name

Byte Offset of Member

Member Type Message

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
NameThis NUL-terminated string provides a description for the opaque type. It is NUL-padded to a + multiple of 8 bytes.
Byte Offset of MemberThis is the byte offset of the member within the datatype.
Member Type MessageThis field is a datatype message describing the datatype of + the member.
+ +Class specific information for Reference (Class 7): + + + + + + + + + + + + + + +
Bit Field Description
BitsMeaning
0-3Type. This four-bit value contains the type of reference described. The values defined are: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0Object Reference: A reference to another object in this HDF5 file.
1Dataset Region Reference: A reference to a region within a dataset in this HDF5 file.
2Internal Reference: A reference to a region within the current dataset. (Not currently implemented)
3-15Reserved
+
15-23Reserved (zero).
+ +There are no properties defined for the reference class. + +Class specific information for Enumeration (Class 8): + + + + + + + + + + + + + + +
Bit Field Description
BitsMeaning
0-15Number of Members. The number of name/value pairs defined for the enumeration type.
16-23Reserved (zero).
+ + + + + + + + + + + + + + + + + + +
Property Description
ByteByteByteByte

Base Type
/

Names


Values

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
Base Type:Each enumeration type is based on some parent type, usually an integer. The information + for that parent type is described recursively by this field.
Names:The name for each name/value pair. Each name is stored as a null terminated ASCII string + in a multiple of eight bytes. The names are in no particular order.
Values:The list of values in the same order as the names. The values are packed (no inter-value + padding) and the size of each value is determined by the parent type.
+ +Class specific information for Variable-Length (Class 9): + + + + + + + + + + + + + + + + + + + + + + +
Bit Field Description
BitsMeaning
0-3Type. This four-bit value contains the type of variable-length datatype described. + The values defined are: + + + + + + + + + + + + + + + + + +
ValueDescription
0Sequence: A variable-length sequence of any sequence of data. Variable-length sequences do not + have padding or character set information.
1String: A variable-length sequence of characters. Variable-length strings have padding and + character set information.
2-15Reserved
4-7Padding type. (variable-length string only). This four-bit value determines the + type of padding used for variable-length strings. The values are the same as for the string padding + type, as follows: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
00 Null terminate: A zero byte marks the end of a string and is guaranteed to be present after + converting a long string to a short string. When converting a short string to a long string, + the value is padded with additional null characters as necessary.
1Null pad: Null characters are added to the end of the value during conversion from a short string to + a longer string. Conversion from a long string to a shorter string simply truncates the value.
2Space pad: Space characters are added to the end of the value during conversion from a short string + to a longer string. Conversion from a long string to a shorter string simply truncates the value. + This is the Fortran representation of the string.
3-15Reserved
+ This value is set to zero for variable-length sequences.
8-11Character Set. (variable-length string only) This four-bit value specifies the + character set to be used for encoding the string: + + + + + + + + + + + + + +
ValueDescription
0ASCII: As of this writing (July 2003, Release 1.6), 8-bit ASCII is the only character set supported. + Therefore, no translations have been defined.
1-15Reserved
+ This value is set to zero for variable-length sequences.
12-23Reserved (zero).
+ + + + + + + + + + + + +
Property Description
ByteByteByteByte

Base Type

+ + + + + + + + + + +
Field NameDescription
Base TypeEach variable-length type is based on some parent type. The information for that parent + type is described recursively by this field.
+ +Class specific information for Array (Class 10): + +There are no bit fields defined for the array class. + +Note that the dimension information defined in the property for this datatype class is independent of +dataspace information for a dataset. The dimension information here describes the dimensionality of the +information within a data element (or a component of an element, if the array datatype is nested within +another datatype) and the dataspace for a dataset describes the location of the elements in a dataset. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Property Description
ByteByteByteByte
DimensionalityReserved (zero)
Dimension \#1 Size
.
.
.
Dimension \#n Size
Permutation Index \#1
.
.
.
Permutation Index \#n

Base Type

+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
DimensionalityThis value is the number of dimensions that the array has.
Dimension \#n SizeThis value is the size of the dimension of the array 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.
Permutation Index \#nThis value is the index permutation used to map each dimension from the canonical representation + to an alternate axis for each dimension. Currently, dimension permutations are not supported and + these indices should be set to the index position minus one (i.e. the first dimension should be + set to 0, the second dimension should be set to 1, etc.)
Base TypeEach array type is based on some parent type. The information for that parent type is described + recursively by this field.
+ +\subsubsection subsubsec_fmt11_dataobject_hdr_ofvmessage Name: Data Storage - Fill Value (Old) +Header Message Type: 0x0004
+Length: varies
+Status: Optional, may not be repeated.
+Description: The fill value message stores a single data point value which is returned +to the application when an uninitialized data point is read from the dataset. The fill value is interpreted +with the same datatype as the dataset. If no fill value message is present then a fill value of all zero is assumed. + +This fill value message is deprecated in favor of the "new" fill value message (Message Type 0x0005) and +is only written to the file for forward compatibility with versions of the HDF5 library before the 1.6.0 +version. Additionally, it only appears for datasets with a user defined fill value (as opposed to the library +default fill value or an explicitly set "undefined" fill value). + +Format of Data: + + + + + + + + + + + + + + +
Fill Value Message (Old)
bytebytebytebyte
Size (4 bytes)

Fill Value

+ + + + + + + + + + + + + + +
Field NameDescription
SizeThis is the size of the Fill Value field in bytes.
Fill ValueThe fill value. The bytes of the fill value are interpreted using the same datatype as for the dataset.
+ +\subsubsection subsubsec_fmt11_dataobject_hdr_fvmessage Name: Data Storage - Fill Value +Header Message Type: 0x0005
+Length: varies
+Status: Required for dataset objects, may not be repeated.
+Description: The fill value message stores a single data value which is returned to the +application when an uninitialized data element is read from a dataset. The fill value is interpreted +with the same datatype as the dataset. + +Format of Data: + + + + + + + + + + + + + + + + + + + + +
Fill Value Message
bytebytebytebyte
VersionSpace Allocation TimeFill Value Write TimeFill Value Defined
Size

Fill Value

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number information is used for changes in the format of the fill value message and + is described here: + + + + + + + + + + + + + + + + + +
VersionDescription
0Never used
1Used by version 1.6.x of the library to encode fill values. In this version, the Size field + is always present. +
2The current version used by the library (version 1.7.3 or later). In this version, the Size + and Fill Value fields are only present if the Fill Value Defined field is set to 1.
+
Space Allocation TimeWhen the storage space for the dataset's raw data will be allocated. The allowed values are: + + + + + + + + + + + + + + + + + +
ValueDescription
1Early allocation. Storage space for the entire dataset should be allocated in the file + when the dataset is created.
2Late allocation. Storage space for the entire dataset should not be allocated until the + dataset is written to.
3Incremental 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 TimeAt 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: + + + + + + + + + + + + + + + + + +
ValueDescription
0On allocation. The fill value is always written to the raw data storage when the storage + space is allocated.
1Never. The fill value should never be written to the raw data storage.
2Fill 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 DefinedThis 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 field.
SizeThis is the size of the Fill Value field in bytes. This field is not present if the Version + field is >1 and the Fill Value Defined field is set to 0.
Fill ValueThe 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 >1 and the Fill Value Defined field + is set to 0.
+ +\subsubsection subsubsec_fmt11_dataobject_hdr_message_0006 Name: Reserved - Not Assigned Yet +Header Message Type: 0x0006
+Length: N/A
+Status: N/A
+Purpose and Description: N/A
+Format of Data: N/A
+Purpose and Description: This message type was skipped during the initial + specification of the file format and may be used in a future expansion to the format. + +\subsubsection subsubsec_fmt11_dataobject_hdr_external Name: Data Storage - External Data Files +Header Message Type: 0x0007
+Length: varies
+Status: Optional, may not be repeated.
+Purpose and Description: The external object message indicates that the data for an +object is stored outside the HDF5 file. The filename of the object is stored as a Universal Resource Location +(URL) of the actual filename containing the data. An external file list record also contains the byte offset +of the start of the data within the file and the amount of space reserved in the file for that data. + + + + + + + + + + + + + + + + + + + + + + + +
External File List Message
bytebytebytebyte
VersionReserved
Allocated SlotsUsed Slots

Heap Address


Slot Definitions...

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number information is used for changes in the format of External File List Message + and is described here: + + + + + + + + + + + + + +
VersionDescription
0Never used.
1The current version used by the library.
ReservedThis field is reserved for future use.
Allocated SlotsThe 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 SlotsThe number of initial slots which contain valid information.
Heap AddressThis is the address of a local name 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 DefinitionsThe slot definitions are stored in order according to the array addresses they represent.
+ + + + + + + + + + + + + + + + + + +
External File List Slot
bytebytebytebyte

Name Offset (<size> bytes)


File Offset (<size> bytes)


Size

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
Name Offset (<size> bytes)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).
File Offset (<size> bytes)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.
SizeThis 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 zeros past the end of the file without failing.
+ +\subsubsection subsubsec_fmt11_dataobject_hdr_layout Name: Data Storage - Layout +Header Message Type: 0x0008
+Length: varies
+Status: Required for datasets, may not be repeated. + +Purpose and Description: Data layout describes how the elements of a multi-dimensional array +are arranged in the linear address space of the file. Three types of data layout are supported: +
    +
  1. Contiguous: The array can be stored in one contiguous area of the file. The layout requires that the + size of the array be constant and does not permit chunking, compression, checksums, encryption, etc. + The message stores the total size of the array and the offset of an element from the beginning of the + storage area is computed as in C.
    2. +
  2. Chunked: The array domain can be regularly decomposed into chunks and each chunk is allocated separately. + This layout supports arbitrary element traversals, compression, encryption, and checksums, and the chunks + can be distributed across external raw data files (these features are described in other messages). + The message stores the size of a chunk instead of the size of the entire array; the size of the entire + array can be calculated by traversing the B-tree that stores the chunk addresses.
    3. +
  3. Compact: The array can be stored in one contiguous block, as part of this object header message (this is + called "compact" storage below).
    4. +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Data Layout Message (Versions 1 and 2)
bytebytebytebyte
VersionDimensionalityLayout ClassReserved
Reserved

Address

Dimension 0 (4-bytes)
Dimension 1 (4-bytes)
...
Dataset Element Size (optional)
Compact Data Size (4-bytes)

Compact Data...

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number information is used for changes in the format of the data layout message and + is described here: + + + + + + + + + + + + + + + + + +
VersionDescription
0Never used.
1Used by version 1.4 and before of the library to encode layout information. Data space is + always allocated when the data set is created.
2Used by version 1.6.x of the library to encode layout information. Data space is allocated + only when it is necessary.
DimensionalityAn array has a fixed dimensionality. This field specifies the number of dimension size fields later + in the message.
Layout ClassThe layout class specifies how the other fields of the layout message are to be interpreted. A value + of one indicates contiguous storage, a value of two indicates chunked storage, while a value of zero + indicates compact storage. Other values will be defined in the future.
AddressFor contiguous storage, this is the address of the first byte of storage. For chunked storage this is + the address of the B-tree that is used to look up the addresses of the chunks. This field is not present + for compact storage. If the version for this message is set to 2, the address may have the "undefined + address" value, to indicate that storage has not yet been allocated for this array.
DimensionsFor contiguous and compact storage the dimensions define the entire size of the array while for chunked storage + they define the size of a single chunk. In all cases, they are in units of array elements (not bytes). The + first dimension stored in the list of dimensions is the slowest changing dimension and the last dimension + stored is the fastest changing dimension.
Dataset Element SizeThe size of a dataset element, in bytes. This field is only present for chunked storage.
Compact Data SizeThis field is only present for compact data storage. It contains the size of the raw data for the + dataset array.
Compact DataThis field is only present for compact data storage. It contains the raw data for the dataset + array.
+ +Version 3 of this message re-structured the format into specific properties that are required for each layout class. + + + + + + + + + + + + + + + + +
Data Layout Message (Version 3)
bytebytebytebyte
VersionLayout Class 

Properties

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number information is used for changes in the format of layout message and is + described here:

+ + + + + + + + + +
VersionDescription
3Used by the version 1.6.3 and later of the library to store properties for each layout class.
Layout ClassThe layout class specifies how the other fields of the layout message are to be interpreted. A value of one + indicates contiguous storage, a value of two indicates chunked storage, while a value of zero indicates + compact storage.
PropertiesThis variable-sized field encodes information specific to each layout class and is described below. If + there is no property information specified for a layout class, the size of this field is zero bytes.
+ +Class-specific information for compact layout (Class 0): (Note: The dimensionality information is in +the Dataspace message) + + + + + + + + + + + + + + + + +
Property Descriptions
bytebytebytebyte
Size 

Raw Data...

+ + + + + + + + + + + + + + +
Field NameDescription
SizeThis field contains the size of the raw data for the dataset array.
Raw DataThis field contains the raw data for the dataset array.
+ +Class-specific information for contiguous layout (Class 1): (Note: The dimensionality information is +in the Dataspace message) + + + + + + + + + + + + + + + +
Property Descriptions
bytebytebytebyte

Address


Size

+ + + + + + + + + + + + + + +
Field NameDescription
AddressThis is the address of the first byte of raw data storage. The address may have the "undefined + address" value, to indicate that storage has not yet been allocated for this array.
SizeThis field contains the size allocated to store the raw data.
+ +Class-specific information for chunked layout (Class 2): + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Property Descriptions
bytebytebytebyte
Dimensionality 

Address

Dimension 0 (4-bytes)
Dimension 1 (4-bytes)
...
Dataset Element Size
+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Dimensionality>A chunk has a fixed dimensionality. This field specifies the number of dimension size fields + later in the message.
AddressThis is the address of the B-tree that is used to look up the addresses of the chunks. The + address may have the undefined address value, to indicate + that storage has not yet been allocated for this array.
DimensionsThese values define the dimension size of a single chunk, in units of array elements (not bytes). + The first dimension stored in the list of dimensions is the slowest changing dimension and the + last dimension stored is the fastest changing dimension.
Dataset Element SizeThe size of a dataset element, in bytes.
+ +\subsubsection subsubsec_fmt11_dataobject_hdr_message_0009 Name: Reserved - Not Assigned Yet +Header Message Type: 0x0009
+Length: N/A
+Status: N/A
+Format of Data: N/A
+Purpose and Description: This message type was skipped during the initial +specification of the file format and may be used in a future expansion to the format. + +\subsubsection subsubsec_fmt11_dataobject_hdr_message_000A Name: Reserved - Not Assigned Yet +Header Message Type: 0x000A
+Length: N/A
+Status: N/A
+Format of Data: N/A +Purpose and Description: This message type was skipped during the initial +specification of the file format and may be used in a future expansion to the format. + +\subsubsection subsubsec_fmt11_dataobject_hdr_filter Name: Data Storage - Filter Pipeline +Header Message Type: 0x000B
+Length: varies
+Status: Optional, may not be repeated.
+Purpose and Description: This message describes the filter pipeline which should be +applied to the data stream by providing filter identification numbers, flags, a name, an client data. + +Format of Data: + + + + + + + + + + + + + + + + + + + +
Filter Pipeline Message
bytebytebytebyte
VersionNumber of FiltersReserved
Reserved

Filter List

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number for this message. This document describes version 1.
Number of FiltersThe total number of filters described by this message. The maximum possible number of filters in a + message is 32.
Filter ListA description of each filter. A filter description appears in the next table.
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Filter Description
bytebytebytebyte
Filter IdentificationName Length
FlagsNumber of Values for Client Data

Name


Client Data

Padding
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Filter IdentificationThis value, often referred to as a filter identifier, is designed to be a unique identifier for + the filter. Values from zero through 32,767 are reserved for filters supported by The HDF Group + in the HDF5 library and for filters requested and supported by third parties. Filters supported + by The HDF Group are documented immediately below. Information on 3rd-party filters can be found + at + https://github.com/HDFGroup/hdf5_plugins/blob/master/docs/RegisteredFilterPlugins.md. + 1
To request a filter identifier, + please contact The HDF Group’s Help Desk at HDF Help Desk. + You will be asked to provide the following information: +
    +
  1. Contact information for the developer requesting the new identifier +
  2. A short description of the new filter +
  3. Links to any relevant information, including licensing information +

+ Values from 32768 to 65535 are reserved for non-distributed uses (for example, internal company usage) + or for application usage when testing a feature. The HDF Group does not track or document the use of + the filters with identifiers from this range.
+ The filters currently in library version 1.6.5 are listed below: + + + + + + + + + + + + + + + + + + + + + + + + + + +
IdentificationNameDescription
1deflateGZIP deflate compression
2shuffleData element shuffling
3fletcher32Fletcher32 checksum
4szipSZIP compression
Name LengthEach filter has an optional null-terminated ASCII name and this field holds the length of the name + including the null termination padded with nulls to be a multiple of eight. If the filter has no name + then a value of zero is stored in this field.
FlagsThe flags indicate certain properties for a filter. The bit values defined so far are: + + + + + + + + + +
ValueDescription
bit 1If set then the filter is an optional filter. During output, if an optional filter fails it will be + silently removed from the pipeline.
Client Data Number of ValuesEach filter can store a few integer values to control how the filter operates. The number of entries + in the Client Data array is stored in this field.
NameIf the Name Length field is non-zero then it will contain the size of this field, a multiple of eight. + This field contains a null-terminated, ASCII character string to serve as a comment/name for the filter.
Client DataThis is an array of four-byte integers which will be passed to the filter function. The Client Data + Number of Values determines the number of elements in the array.
PaddingFour bytes of zeros are added to the message at this point if the Client Data Number of Values field + contains an odd number.
+\anchor FMT11Footnote1Change 1 If you are reading an earlier version of this document, this +link may have changed. If the link does not work, use the latest version of this document on +The HDF Group’s github website, +HDF5 File Format Specification; the link there will always be correct. + +\subsubsection subsubsec_fmt11_dataobject_hdr_attribute Name: Attribute +Header Message Type: 0x000C
+Length: varies
+Status: Optional, may be repeated.
+Description: The Attribute message is used to list objects in the HDF +file which are used as attributes, or "meta-data" about the current object. An attribute is a small dataset; +it has a name, a datatype, a data space, and raw data. Since attributes are stored in the object header they +must be relatively small (<64KB) and can be associated with any type of object which has an object header +(groups, datasets, named types and spaces, etc.). + +Note: Attributes on an object must have unique names. (The HDF5 library currently enforces this by causing +the creation of an attribute with a duplicate name to fail). Attributes on different objects may have the +same name, however. + +Format of Data: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Attribute Message
bytebytebytebyte
VersionReservedName Size
Datatype SizeDataspace Size

Name


Datatype


Dataspace


Data

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number information is used for changes in the format of the attribute message and is + described here: + + + + + + + + + + + + + +
VersionDescription
0Never used.
1Used by the library before version 1.6 to encode attribute message. This version does not + support shared data type.
ReservedThis field is reserved for later use and is set to zero.
Name SizeThe length of the attribute name in bytes including the null terminator. Note that the Name field + below may contain additional padding not represented by this field.
Datatype SizeThe length of the datatype description in the Datatype field below. Note that the Datatype field may contain + additional padding not represented by this field.
Dataspace SizeThe length of the dataspace description in the Dataspace field below. Note that the Dataspace field may contain + additional padding not represented by this field.
NameThe null-terminated attribute name. This field is padded with additional null characters to make it a + multiple of eight bytes.
TypeThe datatype description follows the same format as described for the datatype object header message. + This field is padded with additional zero bytes to make it a multiple of eight bytes.
SpaceThe dataspace description follows the same format as described for the dataspace object header message. + This field is padded with additional zero bytes to make it a multiple of eight bytes.
DataThe raw data for the attribute. The size is determined from the datatype and dataspace descriptions. + This field is not padded with additional bytes.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Attribute Message (Version 2)
bytebytebytebyte
VersionFlagName Size
Type SizeSpace Size

Name


Type


Space


Data

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number information is used for changes in the format of the attribute message and is + described here: + + + + + + + + + +
VersionDescription
2Used by the library of version 1.6.x and after to encode attribute message. This version + supports shared data type. The fields of name, type, and space are not padded with additional + bytes of zero.
Flag>This field indicates whether the data type of this attribute is shared: + + + + + + + + + + + + + +
ValueDescription
0Datatype is not shared.
1Datatype is shared.
Name Size>The length of the attribute name in bytes including the null terminator.
Datatype SizeThe length of the datatype description in the Datatype field below.
Dataspace SizeThe length of the dataspace description in the Dataspace field below.
NameThe null-terminated attribute name. This field is not padded with additional bytes.
DatatypeThe datatype description follows the same format as described for the datatype object + header message. This field is not padded with additional bytes.
DataspaceThe dataspace description follows the same format as described for the dataspace object + header message. This field is not padded with additional bytes.
DataThe raw data for the attribute. The size is determined from the datatype and dataspace + descriptions. This field is not padded with additional zero bytes.
+ +\subsubsection subsubsec_fmt11_dataobject_hdr_comment Name: Object Comment +Header Message Type: 0x000D
+Length: varies
+Status: Optional, may not be repeated.
+Description: The object comment is designed to be a short description of an +object. An object comment is a sequence of non-zero (\0) ASCII characters with +no other formatting included by the library.
+Format of Data: + + + + + + + + + + + +
Name Message
bytebytebytebyte

Comment

+
+ + + + + + + + + +
Field NameDescription
NameA null terminated ASCII character string.
+ +\subsubsection subsubsec_fmt11_dataobject_hdr_modified Name: Object Modification Date & Time (Old) +Header Message Type: 0x000E
+Length: fixed
+Status: Optional, may not be repeated.
+Description: The object modification date and time is a timestamp which +indicates (using ISO-8601 date and time format) the last modification of an object. The time is +updated when any object header message changes according to the system clock where the change was posted. +
+This modification time message is deprecated in favor of the "new" modification time message +(Message Type 0x0012) and is no longer written to the file in versions of the HDF5 library after +the 1.6.0 version.
+Format of Data: + + + + + + + + + + + + + + + + + + + + + + + +
Modification Time Message
bytebytebytebyte
Year
MonthDay of Month
HourMinute
SecondReserved
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
YearThe four-digit year as an ASCII string. For example, 1998. All fields of this message + should be interpreted as coordinated universal time (UTC)
MonthThe month number as a two digit ASCII string where January is 01 and December is + 12.
Day of MonthThe day number within the month as a two digit ASCII string. The first day of the month is + 01.
HourThe hour of the day as a two digit ASCII string where midnight is 00 and 11:00pm + is 23.
MinuteThe minute of the hour as a two digit ASCII string where the first minute of the hour is + 00 and the last is 59.
SecondThe second of the minute as a two digit ASCII string where the first second of the minute is + 00 and the last is 59.
ReservedThis field is reserved and should always be zero.
+ +\subsubsection subsubsec_fmt11_dataobject_hdr_shared Name: Shared Object Message +Header Message Type: 0x000F
+Length: 4 Bytes
+Status: Optional, may be repeated.
+Description: A constant message can be shared among several object headers. A +Shared Object Message contains the address of the object message to be shared. Care must +be exercised to prevent cycles when a message of one object header points to a message in some other +object header. Starting from Version 2 of the Shared Object Message, the Flags field becomes unused. + +Format of Data: + + + + + + + + + + + + + + + +
Shared Object Message (Version 1)
byte + byte + byte + byte +
VersionFlagsReserved
Reserved

Pointer

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number is used when there are changes in the format of a shared object message and + is described here: + + + + + + + + + + + + + +
VersionDescription
0Never used.
1Used by the library before version 1.6.1. In this version, the Flags field is used to + indicate whether the actual message is stored in the global heap (never implemented). + The Pointer field either contains the header message address in the global heap + (never implemented) or the address of the shared object header.
FlagsThe Shared Message message points to a message which is shared among multiple object headers. The + Flags field describes the type of sharing: + + + + + + + + + + + + + +
BitDescription
0If this bit is clear then the actual message is the first message in some other object header; + otherwise the actual message is stored in the global heap. (never implemented).
2-7Reserved (always zero)
PointerThe address of the object header containing the message to be shared.
+ + + + + + + + + + + + + +
Shared Object Message (Version 2)
byte + byte + byte + byte +
VersionFlags 

Pointer

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number is used when there are changes in the format of a shared object message and + is described here: + + + + + + + + + +
VersionDescription
2Used by the library of version 1.6.1 and after. In this version, The Flags field is not used + and the Pointer field contains the address of the object header containing the message to be + shared.
FlagsUnused.
PointerThe address of the object header containing the message to be shared.
+ +\subsubsection subsubsec_fmt11_dataobject_hdr_continuation Name: Object Header Continuation +Header Message Type: 0x0010
+Length: fixed
+Status: Optional, may be repeated.
+Description: The object header continuation is the location in the file of more +header messages for the current data object. This can be used when header blocks become too large, +or are likely to change over time.
+Format of Data: + + + + + + + + + + + + + + +
Object Header Continuation Message
bytebytebytebyte
Offset
Length
+ + + + + + + + + + + + + + +
Field NameDescription
OffsetThis value is the offset in bytes from the beginning of the file where the header continuation + information is located.
LengthThis value is the length in bytes of the header continuation information in the file.
+ +\subsubsection subsubsec_fmt11_dataobject_hdr_stmgroup Name: Group Message +Header Message Type: 0x0011
+Length: fixed
+Status: Required for groups, may not be repeated.
+Description: Each group has a B-tree and a name heap which are pointed to +by this message.
+Format of data: + + + + + + + + + + + + + + +
HGroup Message Layout
bytebytebytebyte

B-tree Address


Heap Address

+ + + + + + + + + + + + + + +
Field NameDescription
B-tree AddressThis value is the offset in bytes from the beginning of the file where the B-tree is located.
Heap AddressThis value is the offset in bytes from the beginning of the file where the group name heap + is located.
+ +\subsubsection subsubsec_fmt11_dataobject_hdr_mod Name: Object Modification Date and Time +Header Message Type: 0x0012
+Length: fixed
+Status: Optional, may not be repeated.
+Description: The object modification date and time is a timestamp which indicates +the last modification of an object. The time is updated when any object header message changes according +to the system clock where the change was posted.
+Format of data: + + + + + + + + + + + + + + + +
Modification Time Message
bytebytebytebyte
VersionReserved
Seconds After Epoch
+ + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number is used for changes in the format of Object Modification Time and is described + here: + + + + + + + + + + + + + +
VersionDescription
0Never used.
1Used by Version 1.6.1 and after of the library to encode time. In this version, the time is + the seconds after Epoch.
ReservedThis field is reserved and should always be zero.
Seconds After EpochThe number of seconds since 0 hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated + Universal Time.
+ +\subsection subsec_fmt11_dataobject_storage Disk Format: Level 2b - Data Object Data Storage +The data for an object is stored separately from the header information in the file and may not actually +be located in the HDF5 file itself if the header indicates that the data is stored externally. The +information for each record in the object is stored according to the dimensionality of the object +(indicated in the dimensionality header message). Multi-dimensional data is stored in C order [same +as current scheme], i.e. the "last" dimension changes fastest. + +Data whose elements are composed of simple number-types are stored in native-endian IEEE format, unless +they are specifically defined as being stored in a different machine format with the architecture-type +information from the number-type header message. This means that each architecture will need to +[potentially] byte-swap data values into the internal representation for that particular machine. + +Data with a variable-length datatype is stored in the global heap of the HDF5 file. Global heap +identifiers are stored in the data object storage. + +Data whose elements are composed of pointer number-types are stored in several different ways depending +on the particular pointer type involved. Simple pointers are just stored as the dataset offset of the +object being pointed to with the size of the pointer being the same number of bytes as offsets in the file. +Dataset region references are stored as a heap-ID which points to the following information within the +file-heap: an offset of the object pointed to, number-type information (same format as header message), +dimensionality information (same format as header message), sub-set start and end information (i.e. a +coordinate location for each), and field start and end names (i.e. a [pointer to the] string indicating +the first field included and a [pointer to the] string name for the last field). + +Data of a compound datatype is stored as a contiguous stream of the items in the structure, with each +item formatted according to its datatype. + +\section sec_fmt11_appendix Appendix +Definitions of various terms used in this document. + +\anchor FMT11UndefinedAddress The "undefined address" for a file is a file address with all bits set, +i.e. 0xffff...ff. + +\anchor FMT11UnlimitedDim The "unlimited size" for a size is a value with all bits set, +i.e. 0xffff...ff. + +*/ diff --git a/doxygen/dox/H5.format.2.0.dox b/doxygen/dox/H5.format.2.0.dox new file mode 100644 index 00000000000..53d84df8885 --- /dev/null +++ b/doxygen/dox/H5.format.2.0.dox @@ -0,0 +1,9285 @@ + +/** \page FMT2 HDF5 File Format Specification Version 2.0 +
    +
  1. @ref sec_fmt2_intro +
      +
    1. @ref subsec_fmt2_intro_doc
      2. +
    2. @ref subsec_fmt2_intro_110
      3. +
    2. +
  2. @ref sec_fmt2_meta +
      +
    1. @ref subsec_fmt2_boot_super
      2. +
    2. @ref subsec_fmt2_boot_driver
      3. +
    3. @ref subsec_fmt2_boot_supext
      4. +
    3. +
  3. @ref sec_fmt2_infra +
      +
    1. @ref subsec_fmt2_infra_btrees +
        +
      1. @ref subsubsec_fmt2_infra_btrees_v1
        2. +
      2. @ref subsubsec_fmt2_infra_btrees_v2
        3. +
      2. +
    2. @ref subsec_fmt2_infra_symboltable
      3. +
    3. @ref subsec_fmt2_infra_symboltableentry
      4. +
    4. @ref subsec_fmt2_infra_localheap
      5. +
    5. @ref subsec_fmt2_infra_globalheap
      6. +
    6. @ref subsec_fmt2_infra_fractalheap
      7. +
    7. @ref subsec_fmt2_infra_freespaceindex
      8. +
    8. @ref subsec_fmt2_infra_sohm
      9. +
    4. +
  4. @ref sec_fmt2_dataobject +
      +
    1. @ref subsec_fmt2_dataobject_hdr +
        +
      1. @ref subsec_fmt2_dataobject_hdr_prefix
        2. +
          +
        1. @ref subsubsec_fmt2_dataobject_hdr_prefix_one
          2. +
        2. @ref subsubsec_fmt2_dataobject_hdr_prefix_two
          3. +
        +
      2. @ref subsec_fmt2_dataobject_hdr_msg
        3. +
          +
        1. @ref subsubsec_fmt2_dataobject_hdr_msg_nil
          2. +
        2. @ref subsubsec_fmt2_dataobject_hdr_msg_simple
          3. +
        3. @ref subsubsec_fmt2_dataobject_hdr_msg_linkinfo
          4. +
        4. @ref subsubsec_fmt2_dataobject_hdr_msg_dtmessage
          5. +
        5. @ref subsubsec_fmt2_dataobject_hdr_msg_ofvmessage
          6. +
        6. @ref subsubsec_fmt2_dataobject_hdr_msg_fvmessage
          7. +
        7. @ref subsubsec_fmt2_dataobject_hdr_msg_link
          8. +
        8. @ref subsubsec_fmt2_dataobject_hdr_msg_external
          9. +
        9. @ref subsubsec_fmt2_dataobject_hdr_msg_layout
          10. +
        10. @ref subsubsec_fmt2_dataobject_hdr_msg_bogus
          11. +
        11. @ref subsubsec_fmt2_dataobject_hdr_msg_groupinfo
          12. +
        12. @ref subsubsec_fmt2_dataobject_hdr_msg_filter
          13. +
        13. @ref subsubsec_fmt2_dataobject_hdr_msg_attribute
          14. +
        14. @ref subsubsec_fmt2_dataobject_hdr_msg_comment
          15. +
        15. @ref subsubsec_fmt2_dataobject_hdr_msg_omodified
          16. +
        16. @ref subsubsec_fmt2_dataobject_hdr_msg_shared
          17. +
        17. @ref subsubsec_fmt2_dataobject_hdr_msg_continuation
          18. +
        18. @ref subsubsec_fmt2_dataobject_hdr_msg_stmgroup
          19. +
        19. @ref subsubsec_fmt2_dataobject_hdr_msg_mod
          20. +
        20. @ref subsubsec_fmt2_dataobject_hdr_msg_btreek
          21. +
        21. @ref subsubsec_fmt2_dataobject_hdr_msg_drvinfo
          22. +
        22. @ref subsubsec_fmt2_dataobject_hdr_msg_attrinfo
          23. +
        23. @ref subsubsec_fmt2_dataobject_hdr_msg_refcount
          24. +
        24. @ref subsubsec_fmt2_dataobject_hdr_msg_fsinfo
          25. +
        +
      2. +
    2. @ref subsec_fmt2_dataobject_storage
      3. +
    +
    5. +
  5. @ref sec_fmt2_appendixa +
  6. @ref sec_fmt2_appendixb +
+ + + +\section sec_fmt2_intro I. Introduction + + + + + + + + + + + + + + +
Figure 1: Relationships among the HDF5 root group, other groups, and objects
\image html FF-IH_FileGroup.gif
Figure 2: HDF5 objects -- datasets, datatypes, or dataspaces
\image html FF-IH_FileObject.gif
+ +The format of an HDF5 file on disk encompasses several key ideas of the HDF4 and AIO file formats as well +as addressing some shortcomings therein. The new format is more self-describing than the HDF4 format and +is more uniformly applied to data objects in the file. + +An HDF5 file appears to the user as a directed graph. The nodes of this graph are the higher-level HDF5 +objects that are exposed by the HDF5 APIs: +\li Groups +\li Datasets +\li Committed (formerly Named) datatypes + +At the lowest level, as information is actually written to the disk, an HDF5 file is made up of the +following objects: +\li A superblock +\li B-tree nodes +\li Heap blocks +\li Object headers +\li Object data +\li Free space + +The HDF5 library uses these lower-level objects to represent the higher-level objects that are then +presented to the user or to applications through the APIs. For instance, a group is an object header that +contains a message that points to a local heap (for storing the links to objects in the group) and to a +B-tree (which indexes the links). A dataset is an object header that contains messages that describe +datatype, dataspace, layout, filters, external files, fill value, and other elements with the layout message +pointing to either a raw data chunk or to a B-tree that points to raw data chunks. + +\subsection subsec_fmt2_intro_doc I.A. This Document +This document describes the lower-level data objects; the higher-level objects and their properties are +described in the \ref UG. + +Three levels of information comprise the file format. Level 0 contains basic information for identifying +and defining information about the file. Level 1 information contains the information about the pieces of a +file shared by many objects in the file (such as a B-trees and heaps). Level 2 is the rest of the file and +contains all of the data objects, with each object partitioned into header information, also known as +metadata, and data. + +The sizes of various fields in the following layout tables are determined by looking at the number of +columns the field spans in the table. There are three exceptions: (1) The size may be overridden by +specifying a size in parentheses, (2) the size of addresses is determined by the Size of Offsets +field in the superblock and is indicated in this document with a superscripted ‘O’, and (3) +the size of length fields is determined by the Size of Lengths field in the superblock and is +indicated in this document with a superscripted ‘L’. + +Values for all fields in this document should be treated as unsigned integers, unless otherwise noted in +the description of a field. Additionally, all metadata fields are stored in little-endian byte order. + +All checksums used in the format are computed with the +Jenkins’ lookup3 algorithm. + +Whenever a bit flag or field is mentioned for an entry, bits are numbered from the lowest bit position +in the entry. + +Various tables in this document aligned with “This space inserted only to align table nicely”. +These entries in the table are just to make the table presentation nicer and do not represent any values +or padding in the file. + +\subsection subsec_fmt2_intro_110 I.B. Changes for HDF5 1.10 +As of October 2015, changes in the file format for HDF5 1.10 have not yet been finalized. + +\section sec_fmt2_meta II. Disk Format: Level 0 - File Metadata + +\subsection subsec_fmt2_boot_super II.A. Disk Format: Level 0A - Format Signature and Superblock +The superblock may begin at certain predefined offsets within the HDF5 file, allowing a block of +unspecified content for users to place additional information at the beginning (and end) of the HDF5 file +without limiting the HDF5 library’s ability to manage the objects within the file itself. This feature +was designed to accommodate wrapping an HDF5 file in another file format or adding descriptive information +to an HDF5 file without requiring the modification of the actual file’s information. The superblock +is located by searching for the HDF5 file signature at byte offset 0, byte offset 512 and at successive +locations in the file, each a multiple of two of the previous location, in other words, at these byte +offsets: 0, 512, 1024, 2048, and so on. + +The superblock is composed of the format signature, followed by a superblock version number and information +that is specific to each version of the superblock. Currently, there are three versions of the superblock +format. Version 0 is the default format, while version 1 is basically the same as version 0 with additional +information when a non-default B-tree ‘K’ value is stored. Version 2 is the latest format, with +some fields eliminated or compressed and with superblock extension and checksum support. + +Version 0 and 1 of the superblock are described below: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Superblock (Versions 0 and 1)
bytebytebytebyte

Format Signature (8 bytes)

Version \# of SuperblockVersion \# of File’s Free Space StorageVersion \# of Root Group Symbol Table EntryReserved (zero)
Version \# of Shared Header Message FormatSize of OffsetsSize of LengthsReserved (zero)
Group Leaf Node KGroup Internal Node K
File Consistency Flags
Indexed Storage Internal Node K1Reserved (zero)1
Base AddressO
Address of File Free Space InfoO
End of File AddressO
Driver Information Block AddressO
Root Group Symbol Table Entry
+\li Items marked with an ‘1’ in the above table are new in version 1 of the superblock. +\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Format SignatureThis 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: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Decimal:13772687013102610
Hexadecimal:894844460d0a1a0a
ASCII C Notation:\211HDF\\r\\n\032\\n
+
+ 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 SuperblockThis 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 InformationThis 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 index is as described in @ref subsec_fmt2_infra_freespaceindex below.
+ This field is present in version 0 and 1 of the superblock.
Version Number of the Root Group Symbol Table EntryThis 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 in @ref subsec_fmt2_infra_symboltableentry below.
+ This field is present in version 0 and 1 of the superblock.
Version Number of the Shared Header Message FormatThis 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 in @ref subsubsec_fmt2_dataobject_hdr_msg_shared below.
+ This field is present in version 0 and 1 of the superblock.
Size of OffsetsThis 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 LengthsThis 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 KEach 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 @ref subsec_fmt2_infra_btrees below.
+ This field is present in version 0 and 1 of the superblock.
Group Internal Node KEach 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 @ref subsec_fmt2_infra_btrees below.
+ This field is present in version 0 and 1 of the superblock.
File Consistency FlagsThis value contains flags to indicate information about the consistency of the information contained + within the file. Currently, the following bit flags are defined: +
    +
  • Bit 0 set indicates that the file is opened for write-access.
    • +
  • Bit 1 set indicates that the file has been verified for consistency and is guaranteed to be + consistent with the format defined in this document.
    • +
  • Bits 2-31 are reserved for future use.
    • +
+ Bit 0 should be set as the first action when a file is opened for write access and should be cleared + only as the final action when closing a file. Bit 1 should be cleared during normal access to a file + and only set after the file’s consistency is guaranteed by the library or a consistency utility.
+ This field is present in version 0+ of the superblock.
Indexed Storage Internal Node KEach internal node of a indexed storage B-tree will have at least this many entries but not more than + twice this many. If the ndex storage B-tree has only one internal node then it might have fewer + entries.
+ This value must be greater than zero.
+ See the @ref subsec_fmt2_infra_btrees below.
+ This field is present in version 1 of the superblock.
Base AddressThis 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 IndexThe file’s free space management is not persistent for version 0 and 1 of the superblock. + Currently this field always contains the @ref FMT2UndefinedAddress "undefined address".
+ This field is present in version 0 and 1 of the superblock.
End of File AddressThis 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 accidentally 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 AddressThis 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 @ref FMT2UndefinedAddress "undefined address".
+ This field is present in version 0 and 1 of the superblock.
Root Group Symbol Table EntryThis is the @ref subsec_fmt2_infra_symboltableentry 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.
+ +Version 2 of the superblock is described below: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Superblock (Version 2)
bytebytebytebyte

Format Signature (8 bytes)

Version \# of SuperblockSize of OffsetsSize of LengthsFile Consistency Flags

Base AddressO


Superblock Extension AddressO


End of File AddressO


Root Group Object Header AddressO

Superblock Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Format SignatureThis field is the same as described for versions 0 and 1 of the superblock.
Version Number of the SuperblockThis field has a value of 2 and has the same meaning as for versions 0 and 1.
Size of OffsetsThis field is the same as described for versions 0 and 1 of the superblock.
Size of LengthsThis field is the same as described for versions 0 and 1 of the superblock.
File Consistency FlagsThis field is the same as described for versions 0 and 1 except that it is smaller (the number + of reserved bits has been reduced from 30 to 6).
Base AddressThis field is the same as described for versions 0 and 1 of the superblock.
Superblock Extension AddressThe field is the address of the object header for the @ref subsec_fmt2_boot_supext. If there is no + extension then this entry should be the @ref FMT2UndefinedAddress "undefined address".
End of File AddressThis field is the same as described for versions 0 and 1 of the superblock.
Root Group Object Header AddressThis is the address of the @ref sec_fmt2_dataobject, which serves as the entry point into the group + graph for the file.
Superblock ChecksumThe checksum for the superblock.
+ +\subsection subsec_fmt2_boot_driver II.B. Disk Format: Level 0B - File Driver Info +The driver information block is an optional region of the file which contains information +needed by the file driver in order to reopen a file. The format is described below: + + + + + + + + + + + + + + + + + + + + + +
Driver Information Block
bytebytebytebyte
VersionReserved
Driver Information Size

Driver Identification (8 bytes)



Driver Information (variable size bytes)


+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number of the Driver Information Block. This document describes version 0.
Driver Information SizeThe size in bytes of the Driver Information field.
Driver IdentificationThis 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 InformationDriver information is stored in a format defined by the file driver (see description below).
+ +The two drivers encoded in the Driver Identification field are as follows: +\li Multi driver:
The identifier for this driver is “NCSAmulti”. This driver provides + a mechanism for segregating raw data and different types of metadata into multiple files. These files + are viewed by the library as a single virtual HDF5 file with a single file address. A maximum of 6 + files will be created for the following data: superblock, B-tree, raw data, global heap, local heap, + and object header. More than one type of data can be written to the same file. +\li Family driver:
The identifier for this driver is “NCSAfami” and is encoded in this + field for library version 1.8 and after. This driver is designed for systems that do not support files + larger than 2 gigabytes by splitting the HDF5 file address space across several smaller files. It does + nothing to segregate metadata and raw data; they are mixed in the address space just as they would be + in a single contiguous file. + +The format of the Driver Information field for the above two drivers are described below: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Multi Driver Information
bytebytebytebyte
Member MappingMember MappingMember MappingMember Mapping
Member MappingMember MappingReservedReserved

Address of Member File 1


End of Address for Member File 1


Address of Member File 2


End of Address for Member File 2


... ...


Address of Member File N


End of Address for Member File N


Name of Member File 1 (variable size)


Name of Member File 2 (variable size)


... ...


Name of Member File N (variable size)

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Member MappingThese fields are integer values from 1 to 6 indicating how the data can be mapped to or + merged with another type of data. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Member MappingDescription
1The superblock data.
2The B-tree data.
3The raw data.
4The global heap data.
5The local heap data.
6The 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.
ReservedThese fields are reserved and should always be zero.
Address of Member File NThis field specifies the virtual address at which the member file starts.
+ N is the number of member files.
End of Address for Member File NThis field is the end of allocated address for the member file.
Name of Member File NThis field is the null-terminated name of 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 for the whole + HDF5 file will substitute the %s in the string.
+ + + + + + + + + + + + +
Family Driver Information
bytebytebytebyte

Size of Member File

+ + + + + + + + + + +
Field NameDescription
Size of Member FileThis field is the size of the member file in the family of files.
+ +\subsection subsec_fmt2_boot_supext II.C. Disk Format: Level 0C - Superblock Extension +The superblock extension is used to store superblock metadata which is either optional, or added +after the version of the superblock was defined. Superblock extensions may only exist when version 2+ of +superblock is used. A superblock extension is an object header which may hold the following messages: +\li \ref subsec_fmt2_infra_sohm containing information to locate the master table of shared object + header message indices. +\li \ref subsubsec_fmt2_dataobject_hdr_msg_btreek containing non-default B-tree ‘K’ values. +\li \ref subsubsec_fmt2_dataobject_hdr_msg_drvinfo containing information needed by the file driver in + order to reopen a file. See also the \ref subsec_fmt2_boot_driver section above. +\li \ref subsubsec_fmt2_dataobject_hdr_msg_fsinfo containing information about file space handling in the file. + +\section sec_fmt2_infra III. Disk Format: Level 1 - File Infrastructure + +\subsection subsec_fmt2_infra_btrees III.A. Disk Format: Level 1A - B-trees and B-tree Nodes +B-trees allow flexible storage for objects which tend to grow in ways that cause the object to be stored +discontiguously. B-trees are described in various algorithms books including "Introduction to Algorithms" by +Thomas H. Cormen, Charles E. Leiserson, and Ronald L. Rivest. The B-trees are used in several places in +the HDF5 file format, when an index is needed for another data structure. + +The version 1 B-tree structure described below is the original index structure, but are limited by some +bugs in our implementation (mainly in how they handle deleting records). The version 1 B-trees are +being phased out in favor of the version 2 B-trees described below, although both types of structures may +be found in the same file, depending on application settings when creating the file. + +\subsubsection subsubsec_fmt2_infra_btrees_v1 III.A.1. Disk Format: Level 1A1 - Version 1 B-trees (B-link Trees) +Version 1 B-trees in HDF5 files an implementation of the B-link tree, in which the sibling nodes at a +particular level in the tree are stored in a doubly-linked list, is described in the “Efficient Locking +for Concurrent Operations on B-trees” paper by Phillip Lehman and S. Bing Yao as published in the + ACM Transactions on Database Systems, Vol. 6, No. 4, December 1981. + +The B-link trees implemented by the file format contain one more key than the number of children. In other +words, each child pointer out of a B-tree node has a left key and a right key. The pointers out of internal +nodes point to sub-trees while the pointers out of leaf nodes point to symbol nodes and raw data chunks. +Aside from that difference, internal nodes and leaf nodes are identical. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
B-link Tree Nodes
bytebytebytebyte
Signature
Node TypeNode LevelEntries Used

Address of Left SiblingO


Address of Right SiblingO

Key 0 (variable size)

Address of Child 0O

Key 1 (variable size)

Address of Child 1O

...
Key 2K (variable size)

Address of Child 2KO

Key 2K+1 (variable size)
+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe ASCII character string “TREE” is used to indicate the beginning of a + B-link tree node. This gives file consistency checking utilities a better chance of reconstructing + a damaged file.
Node TypeEach B-link 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 TypeDescription
0This tree points to group nodes.
1This tree points to a raw data chunk.
+
Node LevelThe 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 UsedThis 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 SiblingThis 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 @ref FMT2UndefinedAddress "undefined address".
Address of Right SiblingThis 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 @ref FMT2UndefinedAddress "undefined address".
Keys and Child PointersEach 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-link tree contains N child + pointers and N+1 keys.
KeyThe 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-4Size of chunk in bytes.
Bytes 4-8Filter 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 fieldsThe 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 indices, each with the value of + 5, followed by a 0 value.
+
Child PointerThe 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 @ref subsec_fmt2_infra_symboltableentry, which contains + information for multiple symbol table entries.
+ +Conceptually, each B-tree node looks like this: + + + + + + + + + + + + + + + + + + + + + + +
key[0] child[0] key[1] child[1] key[2]; ... ... key[N-1] child[N-1] key[N]
+where child[i] is a pointer to a sub-tree (at a level above Level 0) or to data (at Level 0). +Each key[i] describes an item stored by the B-tree (a chunk or an object of a group node). +The range of values represented by child[i] is indicated by key[i] and key[i+1]. + +The following question must next be answered: "Is the value described by key[i] contained in +child[i-1] or in child[i]?" The answer depends on the type of tree. In trees for groups (node +type 0) the object described by key[i] is the greatest object contained in child[i-1] while +in chunk trees (node type 1) the chunk described by key[i] is the least chunk in child[i]. + +That means that key[0] for group trees is sometimes unused; it points to offset zero in the heap, which is +always the empty string and compares as "less-than" any valid object name. + +And key[N] for chunk trees is sometimes unused; it contains a chunk offset which compares as +"greater-than" any other chunk offset and has a chunk byte size of zero to indicate that it is not actually +allocated. + +\subsubsection subsubsec_fmt2_infra_btrees_v2 III.A.2. Disk Format: Level 1A2 - Version 2 B-trees +Version 2 B-trees are “traditional” B-trees, with one major difference. Instead of just using +a simple pointer (or address in the file) to a child of an internal node, the pointer to the child node +contains two additional pieces of information: the number of records in the child node itself, and the +total number of records in the child node and all its descendants. Storing this additional information +allows fast array-like indexing to locate the nth record in the B-tree. + +The entry into a version 2 B-tree is a header which contains global information about the structure of +the B-tree. The root node address field in the header points to the B-tree root node, which is +either an internal or leaf node, depending on the value in the header’s depth field. An +internal node consists of records plus pointers to further leaf or internal nodes in the tree. A leaf +node consists of solely of records. The format of the records depends on the B-tree type (stored in +the header). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Version 2 B-tree Header
bytebytebytebyte
Signature
VersionTypeThis space inserted only to align table nicely
Node Size
Record SizeDepth
Split PercentMerge PercentThis space inserted only to align table nicely

Root Node AddressO

Number of Records in Root NodeThis space inserted only to align table nicely

Total Number of Records in B-treeL

Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe ASCII character string “BTHD” is used to indicate the header of a + version 2 B-link tree node.
VersionThe version number for this B-tree header. This document describes version 0.
TypeThis field indicates the type of B-tree: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0A “testing” B-tree, this value should not be used for storing + records in actual HDF5 files.
1This B-tree is used for indexing indirectly accessed, non-filtered ‘huge’ + fractal heap objects.
2This B-tree is used for indexing indirectly accessed, filtered ‘huge’ + fractal heap objects.
3This B-tree is used for indexing directly accessed, non-filtered ‘huge’ + fractal heap objects.
4This B-tree is used for indexing directly accessed, filtered ‘huge’ + fractal heap objects.
5This B-tree is used for indexing the ‘name’ field for links in indexed + groups.
6This B-tree is used for indexing the ‘creation order’ field for links + in indexed groups.
7This B-tree is used for indexing shared object header messages.
8This B-tree is used for indexing the ‘name’ field for indexed + attributes.
9This B-tree is used for indexing the ‘creation order’ field for + indexed attributes.
+ The format of records for each type is described below.
Node SizeThis is the size in bytes of all B-tree nodes.
Record SizeThis field is the size in bytes of the B-tree record.
DepthThis is the depth of the B-tree.
Split PercentThe percent full that a node needs to increase above before it is split.
Merge PercentThe percent full that a node needs to be decrease below before it is split.
Root Node AddressThis is the address of the root B-tree node. A B-tree with no records will have the + @ref FMT2UndefinedAddress "undefined address" in this field.
Number of Records in Root NodeThis is the number of records in the root node.
Total Number of Records in B-treeThis is the total number of records in the entire B-tree.
ChecksumThis is the checksum for the B-tree header.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Version 2 B-tree Internal Node
bytebytebytebyte
Signature
VersionTypeRecords 0, 1, 2...N-1 (variable size)

Child Node Pointer 0O


Number of Records N0 for Child Node 0 (variable size)

Total Number of Records for Child Node 0 (optional, variable size)

Child Node Pointer 1O


Number of Records N1 for Child Node 1 (variable size)

Total Number of Records for Child Node 1 (optional, variable size)
...

Child Node Pointer NO


Number of Records Nn for Child Node N (variable size)

Total Number of Records for Child Node N (optional, variable size)
Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe ASCII character string “ BTIN ” is used to indicate the internal node + of a B-link tree.
VersionThe version number for this B-tree internal node. This document describes version 0.
TypeThis field is the type of the B-tree node. It should always be the same as the B-tree type in + the header.
RecordsThe 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 PointerThis field is the address of the child node pointed to by the internal node.
Number of Records in Child NodeThis 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 NodeThis 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.
ChecksumThis is the checksum for this node.
+ + + + + + + + + + + + + + + + + + + + +
Version 2 B-tree Leaf Node
bytebytebytebyte
Signature
VersionTypeRecord 0, 1, 2...N-1 (variable size)
Checksum
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe ASCII character string “ BTLF “ is used to indicate the leaf node + of a version 2 B-link tree.
VersionThe version number for this B-tree leaf node. This document describes version 0.
TypeThis field is the type of the B-tree node. It should always be the same as the B-tree type in + the header.
RecordsThe 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.
ChecksumThis is the checksum for this node.
+ +The record layout for each stored (in other words, non-testing) B-tree type is as follows: + + + + + + + + + + + + + + + + + +
Version 2 B-tree, Type 1 Record Layout - Indirectly Accessed, Non-Filtered, + ‘Huge’ Fractal Heap Objects
bytebytebytebyte

Huge Object AddressO


Huge Object LengthL


Huge Object IDL

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + + + + + +
Field NameDescription
Huge Object AddressThe address of the huge object in the file.
Huge Object LengthThe length of the huge object in the file.
Huge Object IDThe heap ID for the huge object.
+ + + + + + + + + + + + + + + + + + + + + + + + +
Version 2 B-tree, Type 2 Record Layout - Indirectly Accessed, Filtered, ‘Huge’ + Fractal Heap Objects
bytebytebytebyte

Filtered Huge Object AddressO


Filtered Huge Object LengthL

Filter Mask

Filtered Huge Object Memory SizeL


Huge Object IDL

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Filtered Huge Object AddressThe address of the filtered huge object in the file.
Filtered Huge Object LengthThe length of the filtered huge object in the file.
Filter MaskA 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 SizeThe size of the de-filtered huge object in memory.
Huge Object IDThe heap ID for the huge object.
+ + + + + + + + + + + + + + + +
Version 2 B-tree, Type 3 Record Layout - Directly Accessed, Non-Filtered, ‘Huge’ + Fractal Heap Objects
bytebytebytebyte

Huge Object AddressO


Huge Object LengthL

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + +
Field NameDescription
Huge Object AddressThe address of the huge object in the file.
Huge Object LengthThe length of the huge object in the file.
+ + + + + + + + + + + + + + + + + + + + + +
Version 2 B-tree, Type 4 Record Layout - Directly Accessed, Filtered, ‘Huge’ + Fractal Heap Objects
bytebytebytebyte

Filtered Huge Object AddressO


Filtered Huge Object LengthL

Filter Mask

Filtered Huge Object Memory SizeL

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Filtered Huge Object AddressThe address of the filtered huge object in the file.
Filtered Huge Object LengthThe length of the filtered huge object in the file.
Filter MaskA 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 SizeThe size of the de-filtered huge object in memory.
+ + + + + + + + + + + + + + + + + + +
Version 2 B-tree, Type 5 Record Layout - Link Name for Indexed Group
bytebytebytebyte
Hash of Name
ID (bytes 1-4)
ID (bytes 5-7)
+ + + + + + + + + + + + + + +
Field NameDescription
HashThis 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.
IDThis is a 7-byte sequence of bytes and is the heap ID for the link record in the group’s + fractal heap.
+ + + + + + + + + + + + + + + + + + + +
Version 2 B-tree, Type 6 Record Layout - Creation Order for Indexed Group
bytebytebytebyte

Creation Order (8 bytes)

ID (bytes 1-4)
ID (bytes 5-7)
+ + + + + + + + + + + + + + +
Field NameDescription
Creation OrderThis field is the creation order value for the link.
IDThis is a 7-byte sequence of bytes and is the heap ID for the link record in the group’s + fractal heap.
+ + + + + + + + + + + + + + + + + + + + + + +
Version 2 B-tree, Type 7 Record Layout - Shared Object Header Messages + (Sub-Type 0 - Message in Heap)
bytebytebytebyte
Message LocationThis space inserted only to align table nicely
Hash
Reference Count

Heap ID (8 bytes)

+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Message LocationThis field Indicates the location where the message is stored: + + + + + + + + + + + + + +
ValueDescription
0Shared message is stored in shared message index heap.
1Shared message is stored in object header.
+
HashThis field is hash value of the shared message. The hash value is the Jenkins’ lookup3 + checksum algorithm applied to the shared message.
Reference CountThe number of objects which reference this message.
Heap IDThis is an 8-byte sequence of bytes and is the heap ID for the shared message in the shared + message index’s fractal heap.
+ + + + + + + + + + + + + + + + + + + + + + + + +
Version 2 B-tree, Type 7 Record Layout - Shared Object Header Messages + (Sub-Type 1 - Message in Object Header)
bytebytebytebyte
Message LocationThis space inserted only to align table nicely
Hash
Reserved (zero)Message TypeObject Header Index

Object Header AddressO

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Message LocationThis field Indicates the location where the message is stored: + + + + + + + + + + + + + +
ValueDescription
0Shared message is stored in shared message index heap.
1Shared message is stored in object header.
+
HashThis field is hash value of the shared message. The hash value is the Jenkins’ lookup3 + checksum algorithm applied to the shared message.
Message TypeThe object header message type of the shared message.
Object Header IndexThis field indicates that the shared message is the nth message of its type in the + specified object header.
Object Header AddressThe address of the object header containing the shared message.
+ + + + + + + + + + + + + + + + + + + + + + +
Version 2 B-tree, Type 8 Record Layout - Attribute Name for Indexed Attributes
bytebytebytebyte

Heap ID (8 bytes)

Message FlagsThis space inserted only to align table nicely
Creation Order
Hash of Name
+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Heap IDThis is an 8-byte sequence of bytes and is the heap ID for the attribute in the object’s + attribute fractal heap.
Message FlagsThe object header message flags for the attribute message.
Creation OrderThis field is the creation order value for the attribute.
HashThis 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.
+ + + + + + + + + + + + + + + + + + + +
Version 2 B-tree, Type 9 Record Layout- Creation Order for Indexed Attributes
bytebytebytebyte

Heap ID (8 bytes)

Message FlagsThis space inserted only to align table nicely
Creation Order
+ + + + + + + + + + + + + + + + + + + +
Field NameDescription
Heap IDThis is an 8-byte sequence of bytes and is the heap ID for the attribute in the object’s + attribute fractal heap.
Message FlagsThe object header message flags for the attribute message.
Creation OrderThis field is the creation order value for the attribute.
+ +\subsection subsec_fmt2_infra_symboltable III.B. Disk Format: Level 1B - Group Symbol Table Nodes +A group is an object internal to the file that allows arbitrary nesting of objects within the file (including +other groups). A group maps a set of link names in the group to a set of relative file addresses of objects +in the file. Certain metadata for an object to which the group points can be cached in +object’s header. + +An HDF5 object name space can be stored hierarchically by partitioning the name into components and storing +each component as a link in a group. The link for a non-ultimate component points to the group containing the +next component. The link for the last component points to the object being named. + +One implementation a group is a collection of symbol table nodes indexed by a B-link tree. Each symbol table +node contains entries for one or more links. If an attempt is made to add a link to an already full +symbol table node containing 2K entries, then the node is split and one node contains K +symbols and the other contains K+1 symbols. + + + + + + + + + + + + + + + + + + + + +
Symbol Table Node (A Leaf of a B-link tree)
bytebytebytebyte
Signature
Version NumberReserved (zero)Number of Symbols


Group Entries


+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe 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 NumberThe version number for the symbol table node. This document describes version 1. (There is no version + ‘0’ of the symbol table node)
Number of SymbolsAlthough 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.
Group EntriesEach 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 @ref subsec_fmt2_boot_super.
+ +\subsection subsec_fmt2_infra_symboltableentry III.C. Disk Format: Level 1C - Symbol Table Entry +Each symbol table entry in a symbol table node is designed to allow for very fast browsing of stored objects. +Toward that design goal, the symbol table entries include space for caching certain constant metadata from the +object header. + + + + + + + + + + + + + + + + + + + + + + + + +
Symbol Table Entry
bytebytebytebyte
Link Name OffsetO
Object Header AddressO
Cache Type
Reserved (zero)


Scratch-pad Space (16 bytes)


+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Link Name OffsetThis is the byte offset into the group’s local heap for the name of the link. The name is null + terminated.
Object Header AddressEvery 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 TypeThe cache type is determined from the object header. It also determines the format for the scratch-pad + space.
+ + + + + + + + + + + + + + + + + +
Type:Description:
0No 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.
1Group object header metadata is cached in the scratch-pad space. This implies that the symbol table + entry refers to another group.
2The 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.
+
ReservedThese 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 SpaceThis space is used for different purposes, depending on the value of the Cache Type field. Any meta-data + 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.
+ +\subsubsection subsubsec_fmt2_infra_symboltableentry_scratch Format of the Scratch-pad Space +The symbol table entry scratch-pad space is formatted according to the value in the Cache Type field. + +If the Cache Type field contains the value zero ((0)) then no information is stored in the +scratch-pad space. + +If the Cache Type field contains the value one (1), then the scratch-pad space contains +cached metadata for another object header in the following format: + + + + + + + + + + + + + +
Object Header Scratch-pad Format
bytebytebytebyte
Address of B-treeO
Address of Name HeapO
+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + +
Field NameDescription
Address of B-treeThis is the file address for the root of the group’s B-tree.
Address of Name HeapThis is the file address for the group’s local heap, in which are stored the group’s + symbol names.
+ +If the Cache Type field contains the value two ((2)), then the scratch-pad space contains +cached metadata for a symbolic link in the following format: + + + + + + + + + + + +
Symbolic Link Scratch-pad Format
bytebytebytebyte
Offset to Link Value
+ + + + + + + + + + +
Field NameDescription
Offset to Link ValueThe 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.
+ +\subsection subsec_fmt2_infra_localheap III.D. Disk Format: Level 1D - Local Heaps +A local heap is a collection of small pieces of data that are particular to a single object in the HDF5 file. +Objects can be inserted and removed from the heap at any time. The address of a heap does not change once +the heap is created. For example, a group stores addresses of objects in symbol table nodes with the names +of links stored in the group’s local heap. + + + + + + + + + + + + + + + + + + + + + + + + +
Local Heap
bytebytebytebyte
Signature
VersionReserved (zero)
Data Segment SizeL
Offset to Head of Free-listL
Address of Data SegmentO
+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe 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.
VersionEach 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 SizeThe 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-listThis is the offset within the heap data segment of the first free block (or the + @ref FMT2UndefinedAddress "undefined address" if there is no 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 SegmentThe 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.
+ +Objects within a local heap should be aligned on an 8-byte boundary. + +\subsection subsec_fmt2_infra_globalheap III.E. Disk Format: Level 1E - Global Heap +Each HDF5 file has a global heap which stores various types of information which is typically shared between +datasets. The global heap was designed to satisfy these goals: +
    +
  1. Repeated access to a heap object must be efficient without resulting in repeated file I/O requests. + Since global heap objects will typically be shared among several datasets, it is probable that the + object will be accessed repeatedly.
    2. +
  2. Collections of related global heap objects should result in fewer and larger I/O requests. For + instance, a dataset of object references will have a global heap object for each reference. Reading + the entire set of object references should result in a few large I/O requests instead of one small + I/O request for each reference.
    3. +
  3. It should be possible to remove objects from the global heap and the resulting file hole should be + eligible to be reclaimed for other uses.
    4. +
+ +The implementation of the heap makes use of the memory management already available at the file level and +combines that with a new object called a collection to achieve goal B. The global heap is +the set of all collections. Each global heap object belongs to exactly one collection and each collection +contains one or more global heap objects. For the purposes of disk I/O and caching, a collection is treated +as an atomic object, addressing goal A. + +When a global heap object is deleted from a collection (which occurs when its reference count falls to zero), +objects located after the deleted object in the collection are packed down toward the beginning of the +collection and the collection’s global heap object 0 is created (if possible) or its size is increased +to account for the recently freed space. There are no gaps between objects in each collection, with the possible +exception of the final space in the collection, if it is not large enough to hold the header for the +collection’s global heap object 0. These features address goal C. + +The HDF5 library creates global heap collections as needed, so there may be multiple collections throughout +the file. The set of all of them is abstractly called the “global heap”, although they do not +actually link to each other, and there is no global place in the file where you can discover all of the +collections. The collections are found simply by finding a reference to one through another object in the file. +For example, data of variable-length datatype elements is stored in the global heap and is accessed via a +global heap ID. The format for global heap IDs is described at the end of this section. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
A Global Heap Collection
bytebytebytebyte
Signature
VersionReserved (zero)

Collection SizeL


Global Heap Object 1


Global Heap Object 2


...


Global Heap Object N


Global Heap Object 0 (free space)

+\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe 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.
VersionEach 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 SizeThis 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 NThe objects are stored in any order with no intervening unused space.
Global Heap Object 0Global 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 the collection contains no free space.
+ + + + + + + + + + + + + + + + + + + + + + +
Global Heap Object
bytebytebytebyte
Heap Object IndexReference Count
Reserved (zero)

Object SizeL


Object Data

+\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Heap Object IndexEach 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 CountAll 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.
ReservedZero 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 DataThe object data is treated as a one-dimensional array of bytes to be interpreted by the caller.
+ +
+The format for the ID used to locate an object in the global heap is described here: + + + + + + + + + + + + + + +
Global Heap ID
bytebytebytebyte

Collection AddressO

Object Index
+\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + +
Field NameDescription
Collection AddressThis field is the address of the global heap collection where the data object is stored.
IDThis field is the index of the data object within the global heap collection.
+ +\subsection subsec_fmt2_infra_fractalheap III.F. Disk Format: Level 1F - Fractal Heap +Each fractal heap consists of a header and zero or more direct and indirect blocks (described below). +The header contains general information as well as initialization parameters for the doubling +table. The Root Block Address in the header points to the first direct or indirect block in +the heap. + +Fractal heaps are based on a data structure called a doubling table. A doubling table provides +a mechanism for quickly extending an array-like data structure that minimizes the number of empty blocks +in the heap, while retaining very fast lookup of any element within the array. More information on +fractal heaps and doubling tables can be found in the RFC +“\ref_rfc20070115 .” + +The fractal heap implements the doubling table structure with indirect and direct blocks. Indirect +blocks in the heap do not actually contain data for objects in the heap, their “size” is +abstract - they represent the indexing structure for locating the direct blocks in the doubling table. +Direct blocks contain the actual data for objects stored in the heap. + +All indirect blocks have a constant number of block entries in each row, called the width +of the doubling table (stored in the heap header). The number of rows for each indirect block in the +heap is determined by the size of the block that the indirect block represents in the doubling table +(calculation of this is shown below) and is constant, except for the “root” indirect block, +which expands and shrinks its number of rows as needed. + +Blocks in the first two rows of an indirect block are Starting Block Size number of +bytes in size, and the blocks in each subsequent row are twice the size of the blocks in the previous +row. In other words, blocks in the third row are twice the Starting Block Size, blocks in the +fourth row are four times the Starting Block Size, and so on. Entries for blocks up to the +Maximum Direct Block Size point to direct blocks, and entries for blocks greater than that size +point to further indirect blocks (which have their own entries for direct and indirect blocks). + +The number of rows of blocks, nrows, in an indirect block of size iblock_size is given +by the following expression:

+nrows = (log2(iblock_size) - log2(<Starting Block Size> +* <Width>)) + 1 + +The maximum number of rows of direct blocks, max_dblock_rows, in any indirect block of a fractal +heap is given by the following expression:

+max_dblock_rows = (log2(<Max. Direct Block Size>) - +log2(<Starting Block Size>)) + 2 + +Using the computed values for nrows and max_dblock_rows, along with the Width +of the doubling table, the number of direct and indirect block entries (K and N in the +indirect block description, below) in an indirect block can be computed:

+K = MIN(nrows, max_dblock_rows) * Width

+If nrows is less than or equal to max_dblock_rows, N is 0. Otherwise, N +is simply computed:

+N = K - (max_dblock_rows * Width) + +The size indirect blocks on disk is determined by the number of rows in the indirect block (computed above). +The size of direct blocks on disk is exactly the size of the block in the doubling table. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fractal Heap Header
bytebytebytebyte
Signature
VersionThis space inserted only to align table nicely
Heap ID LengthI/O Filters’ Encoded Length
FlagsThis space inserted only to align table nicely
Maximum Size of Managed Objects

Next Huge Object IDL


v2 B-tree Address of Huge ObjectsO


Amount of Free Space in Managed BlocksL


Address of Managed Block Free Space ManagerO


Amount of Managed Space in HeapL


Amount of Allocated Managed Space in HeapL


Offset of Direct Block Allocation Iterator in Managed SpaceL


Number of Managed Objects in HeapL


Size of Huge Objects in HeapL


Number of Huge Objects in HeapL


Size of Tiny Objects in HeapL


Number of Tiny Objects in HeapL

Table WidthThis space insertedonly to align table nicely

Starting Block SizeL


Maximum Direct Block SizeL

Maximum Heap SizeStarting \# of Rows in Root Indirect Block

Address of Root BlockO

Current \# of Rows in Root Indirect BlockThis space inserted only to align table nicely

Size of Filtered Root Direct Block (optional)L

I/O Filter Mask (optional)
I/O Filter Information (optional, variable size)
Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock."Size of Offset field in the superblocks." +\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe 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.
VersionThis document describes version 0.
Heap ID LengthThis is the length in bytes of heap object IDs for this heap.
I/O Filters’ Encoded LengthThis is the size in bytes of the encoded I/O Filter Information.
FlagsThis field is the heap status flag and is a bit field indicating additional information about + the fractal heap. + + + + + + + + + + + + + + + + + +
Bit(s)Description
0If 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. +
1If set, the direct blocks in the heap are checksummed.
2-7Reserved
Maximum Size of Managed ObjectsThis 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 IDThis is the next ID value to use for a huge object in the heap.
v2 B-tree Address of Huge ObjectsThis is the address of the @ref subsubsec_fmt2_infra_btrees_v2 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 & + 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 BlocksThis is the total amount of free space in managed direct blocks (in bytes).
Address of Managed Block Free Space ManagerThis is the address of the @ref subsec_fmt2_infra_freespaceindex + for managed blocks.
Amount of Managed Space in HeapThis 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 HeapThis 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 SpaceThis 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 HeapThis is the number of managed objects in the heap.
Size of Huge Objects in HeapThis is the total size of huge objects in the heap (in bytes).
Number of Huge Objects in HeapThis is the number of huge objects in the heap.
Size of Tiny Objects in HeapThis is the total size of tiny objects that are packed in heap IDs (in bytes).
Number of Tiny Objects in HeapThis is the number of tiny objects that are packed in heap IDs.
Table WidthThis is the number of columns in the doubling table for managed blocks. This value + must be a power of two.
Starting Block SizeThis 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 SizeThis is the maximum size allowed for a managed direct block. Objects inserted into the heap that + are larger than this value (less the \# of bytes of direct block prefix/suffix) are stored as + ‘huge’ objects. This value must be a power of two.
Maximum Heap SizeThis 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 \# 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 BlockThis 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 BlockThis is the address of the root block for the heap. It can be the + @ref FMT2UndefinedAddress "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 BlockThis 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 BlockThis 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 MaskThis 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 + @ref subsubsec_fmt2_infra_btrees_v1. This field is only stored in the header if the I/O Filters’ + Encoded Length is greater than 0.
I/O Filter InformationThis 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 @ref subsubsec_fmt2_dataobject_hdr_msg_filter message. The size + of this field is determined by I/O Filters’ Encoded Length.
ChecksumThis is the checksum for the header.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fractal Heap Direct Block
bytebytebytebyte
Signature
VersionThis space inserted only to align table nicely

Heap Header AddressO

Block Offset (variable size)
Checksum (optional)

Object Data (variable size)

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe 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.
VersionThis document describes version 0.
Heap Header AddressThis is the address for the fractal heap header that this block belongs to. This field is + principally used for file integrity checking.
Block OffsetThis 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.
ChecksumThis 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 DataThis 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).
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fractal Heap Indirect Block
bytebytebytebyte
Signature
VersionThis space inserted only to align table nicely

Heap Header AddressO

Block Offset (variable size)

Child Direct Block \#0 AddressO


Size of Filtered Direct Block \#0 (optional) L

Filter Mask for Direct Block \#0 (optional)

Child Direct Block \#1 AddressO


Size of Filtered Direct Block \#1 (optional)L

Filter Mask for Direct Block \#1 (optional)
...

Child Direct Block \#K-1 AddressO


Size of Filtered Direct Block \#K-1 (optional)L

Filter Mask for Direct Block \#K-1 (optional)

Child Indirect Block \#0 AddressO


Child Indirect Block \#1 AddressO

...

Child Indirect Block \#N-1 AddressO

Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe 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.
VersionThis document describes version 0.
Heap Header AddressThis is the address for the fractal heap header that this block belongs to. This field is principally + used for file integrity checking.
Block OffsetThis 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 AddressThis 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 \#KThis 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 \#KThis 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 @ref subsubsec_fmt2_infra_btrees_v1. If + no I/O filters are present for this heap, this field is not present.
Child Indirect Block \#N AddressThis 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.
ChecksumThis is the checksum for the indirect block.
+ +An object in the fractal heap is identified by means of a fractal heap ID, which encodes information to +locate the object in the heap. Currently, the fractal heap stores an object in one of three ways, +depending on the object’s size: + + + + + + + + + + + + + + + + + +
TypeDescription
TinyWhen an object is small enough to be encoded in the heap ID, the object’s data is embedded + in the fractal heap ID itself. There are 2 sub-types for this type of object: normal and extended. + The sub-type for tiny heap IDs depends on whether the heap ID is large enough to store objects + greater than 16 bytes or not. If the heap ID length is 18 bytes or smaller, the ‘normal’ + tiny heap ID form is used. If the heap ID length is greater than 18 bytes in length, the + “extended” form is used. See format description below for both sub-types.
HugeWhen the size of an object is larger than Maximum Size of Managed Objects in the + Fractal Heap Header, the object’s data is stored on its own in the file and the object + is tracked/indexed via a version 2 B-tree. All huge objects for a particular fractal heap use the same + v2 B-tree. All huge objects for a particular fractal heap use the same format for their huge object IDs. +
Depending on whether the IDs for a heap are large enough to hold the object’s retrieval + information and whether I/O pipeline filters are applied to the heap’s objects, 4 sub-types are + derived for huge object IDs for this heap: + + + + + + + + + + + + + + + + + + + + + +
Sub-typeDescription
Directly accessed, non-filteredThe object’s address and length are embedded in the fractal heap ID itself and the + object is directly accessed from them. This allows the object to be accessed without resorting + to the B-tree.
Directly accessed, filteredThe filtered object’s address, length, filter mask and de-filtered size are embedded + in the fractal heap ID itself and the object is accessed directly with them. This allows the + object to be accessed without resorting to the B-tree.
Indirectly accessed, non-filteredThe object is located by using a B-tree key embedded in the fractal heap ID to retrieve the + address and length from the version 2 B-tree for huge objects. Then, the address and length + are used to access the object.
Indirectly accessed, filteredThe object is located by using a B-tree key embedded in the fractal heap ID to retrieve the + filtered object’s address, length, filter mask and de-filtered size from the version + 2 B-tree for huge objects. Then, this information is used to access the object.
ManagedWhen the size of an object does not meet the above two conditions, the object is stored and managed + via the direct and indirect blocks based on the doubling table.
+ +The specific format for each type of heap ID is described below: + + + + + + + + + + + + + + + +
Fractal Heap ID for Tiny Objects (sub-type 1 - ‘Normal’)
bytebytebytebyte
Version, Type & LengthThis space inserted only to align table nicely

Data (variable size)
+ + + + + + + + + + + + + + +
Field NameDescription
Version, Type & LengthThis is a bit field with the following definition: + + + + + + + + + + + + + + + + + +
BitDescription
6-7The current version of ID format. This document describes version 0.
4-5The ID type. Tiny objects have a value of 2. +
0-3The 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.
DataThis is the data for the object.
+ + + + + + + + + + + + + + + + + +
Fractal Heap ID for Tiny Objects (sub-type 2 - ‘Extended’)
bytebytebytebyte
Version, Type & LengthExtended LengthThis space inserted only to align table nicely
Data (variable size)
+ + + + + + + + + + + + + + + + + + +
Field NameDescription
Version, Type & LengthThis is a bit field with the following definition: + + + + + + + + + + + + + + + + + +
BitDescription
6-7The current version of ID format. This document describes version 0.
4-5The ID type. Tiny objects have a value of 2.
0-3These 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 LengthThis 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.
DataThis is the data for the object.
+ + + + + + + + + + + + + + + + +
Fractal Heap ID for Huge Objects (sub-type 1 & 2): indirectly accessed, + non-filtered/filtered
bytebytebytebyte
Version & TypeThis space inserted only to align table nicely

v2 B-tree KeyL (variable size)

+\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + +
Field NameDescription
Version & TypeThis is a bit field with the following definition: + + + + + + + + + + + + + + + + + +
BitDescription
6-7The current version of ID format. This document describes version 0.
4-5The ID type. Huge objects have a value of 1.
0-3Reserved.
v2 B-tree KeyThis 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 @ref subsubsec_fmt2_infra_btrees_v2 + records sub-type 1 & 2 for a description of the fields. New key values are derived from Next + Huge Object ID in the Fractal Heap Header.
+ + + + + + + + + + + + + + + + + + + +
Fractal Heap ID for Huge Objects (sub-type 3): directly accessed, non-filtered
bytebytebytebyte
Version & TypeThis space inserted only to align table nicely

Address O


Length L

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + + + + + +
Field NameDescription
Version & TypeThis is a bit field with the following definition: + + + + + + + + + + + + + + + + + +
BitDescription
6-7The current version of ID format. This document describes version 0.
4-5The ID type. Huge objects have a value of 1.
0-3Reserved.
AddressThis field is the address of the object in the file.
LengthThis field is the length of the object in the file.
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Fractal Heap ID for Huge Objects (sub-type 4): directly accessed, filtered
bytebytebytebyte
Version & TypeThis space inserted only to align table nicely

Address O


Length L

Filter Mask

De-filtered Size L

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Version & TypeThis is a bit field with the following definition: + + + + + + + + + + + + + + + + + +
BitDescription
6-7The current version of ID format. This document describes version 0.
4-5The ID type. Huge objects have a value of 1.
0-3Reserved.
AddressThis field is the address of the filtered object in the file.
LengthThis field is the length of the filtered object in the file.
Filter MaskThis field is the I/O pipeline filter mask for the filtered object in the file.
Filtered SizeThis field is the size of the de-filtered object in the file.
+ + + + + + + + + + + + + + + + + + + +
Fractal Heap ID for Managed Objects
bytebytebytebyte
Version & TypeThis space inserted only to align table nicely
Offset (variable size)
Length (variable size)
+ + + + + + + + + + + + + + + + + + +
Field NameDescription
Version & TypeThis is a bit field with the following definition: + + + + + + + + + + + + + + + + + +
BitDescription
6-7The current version of ID format. This document describes version 0.
4-5The ID type. Managed objects have a value of 0.
0-3Reserved.
OffsetThis 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.
LengthThis 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.
+ +\subsection subsec_fmt2_infra_freespaceindex III.G. Disk Format: Level 1G - Free-space Index +Free-space managers are used to describe space within a heap or the entire HDF5 file that is not currently +used for that heap or file. + +The free-space manager header contains metadata information about the space being tracked, along +with the address of the list of free space sections which actually describes the free space. The +header records information about free-space sections being tracked, creation parameters for handling +free-space sections of a client, and section information used to locate the collection of free-space sections. + +The free-space section list stores a collection of free-space sections that is specific to each +client of the free-space manager. For example, the fractal heap is a client of the free space +manager and uses it to track unused space within the heap. There are 4 types of section records for the +fractal heap, each of which has its own format, listed below. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Free-space Manager Header
bytebytebytebyte
Signature
VersionClient IDThis space inserted only to align table nicely

Total Space TrackedL


Total Number of SectionsL


Number of Serialized SectionsL


Number of Un-Serialized SectionsL

Number of Section ClassesThis space inserted only to align table nicely
Shrink PercentExpand Percent
Size of Address SpaceThis space inserted only to align table nicely

Maximum Section Size L


Address of Serialized Section ListO


Size of Serialized Section List UsedL


Allocated Size of Serialized Section ListL

Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe 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.
VersionThis is the version number for the Free-space Manager Header and this document describes version 0.
Client IDThis is the client ID for identifying the user of this free-space manager: + + + + + + + + + + + + + + + + + +
IDDescription
0Fractal heap
1File
2+Reserved.
Total Space TrackedThis is the total amount of free space being tracked, in bytes.
Total Number of SectionsThis is the total number of free-space sections being tracked.
Number of Serialized SectionsThis is the number of serialized free-space sections being tracked.
Number of Un-Serialized SectionsThis 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 ClassesThis is the number of section classes handled by this free space manager for the free-space client.
Shrink PercentThis is the percent of current size to shrink the allocated serialized free-space section list.
Expand PercentThis is the percent of current size to expand the allocated serialized free-space section list.
Size of Address SpaceThis is the size of the address space that free-space sections are within. This is stored as the + log2 of the actual value (in other words, the number of bits required to store values + within that address space).
Maximum Section SizeThis is the maximum size of a section to be tracked.
Address of Serialized Section ListThis is the address where the serialized free-space section list is stored.
Size of Serialized Section List UsedThis 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 ListThis is the size of serialized free-space section list actually allocated (in bytes).
ChecksumThis is the checksum for the free-space manager header.
+ +The free-space sections being managed are stored in a free-space section list, described below. +The sections in the free-space section list are stored in the following way: a count of the number of sections +describing a particular size of free space and the size of the free-space described (in bytes), followed +by a list of section description records; then another section count and size, followed by the list of +section descriptions for that size; and so on. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Free-space Section List
bytebytebytebyte
Signature
VersionThis space inserted only to align table nicely

Free-space Manager Header AddressO

Number of Section Records in Set \#0 (variable size)
Size of Free-space Section Described in Record Set \#0 (variable size)
Record Set \#0 Section Record \#0 Offset (variable size)
Record Set \#0 Section Record #0 TypeThis space inserted only to align table nicely
Record Set \#0 Section Record \#0 Data (variable size)
...
Record Set \#0 Section Record \#K-1 Offset (variable size)
Record Set \#0 Section Record \#K-1 TypeThis space inserted only to align table nicely
Record Set \#0 Section Record \#K-1 Data (variable size)
Number of Section Records in Set \#1 (variable size)
Size of Free-space Section Described in Record Set \#1 (variable size)
Record Set \#1 Section Record \#0 Offset (variable size)
Record Set \#1 Section Record \#0 TypeThis space inserted only to align table nicely
Record Set \#1 Section Record \#0 Data (variable size)
...
Record Set \#1 Section Record \#K-1 Offset (variable size)
Record Set \#1 Section Record \#K-1 TypeThis space inserted only to align table nicely
Record Set \#1 Section Record \#K-1 Data (variable size)
...
...
Number of Section Records in Set \#N-1 (variable size)
Size of Free-space Section Described in Record Set \#N-1 (variable size)
Record Set \#N-1 Section Record \#0 Offset (variable size)
Record Set \#N-1 Section Record \#0 TypeThis space inserted only to align table nicely
Record Set \#N-1 Section Record \#0 Data (variable size)
...
Record Set \#N-1 Section Record \#K-1 Offset (variable size)
Record Set \#N-1 Section Record \#K-1 TypeThis space inserted only to align table nicely
Record Set \#N-1 Section Record \#K-1 Data (variable size)
Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe 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.
VersionThis is the version number for the Free-space Section List and this document describes version 0.
Free-space Manager Header AddressThis is the address of the Free-space Manager Header. This field is principally used for file + integrity checking.
Number of Section Records for Set \#NThis 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 \#NThis 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 OffsetThis 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 TypeThis 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: + + + + + + + + + + + + + +
TypeDescription
0File’s section (a range of actual bytes in file)
1+Reserved.
+
The defined record types for a fractal heap client are: + + + + + + + + + + + + + + + + + + + + + + + + + +
TypeDescription
0Fractal heap “single” section
1Fractal heap “first row” section
2Fractal heap “normal row” section
3Fractal heap “indirect” section
4+Reserved.
Record Set \#N Section \#K DataThis is the section-type specific information for each record in the record set, described below.
ChecksumThis is the checksum for the Free-space Section List.
+ +The section-type specific data for each free-space section record is described below: + + + + + +
File’s Section Data Record
No additional record data stored
+
+ + + + + +
Fractal Heap “Single” Section Data Record
No additional record data stored
+
+ + + + + +
Fractal Heap “First Row” Section Data Record
Same format as “indirect” section data
+
+ + + + + +
Fractal Heap “Normal Row” Section Data Record
No additional record data stored
+
+ + + + + + + + + + + + + + + + + + + +
Fractal Heap “Indirect” Section Data Record
bytebytebytebyte
Fractal Heap Indirect Block Offset (variable size)
Block Start RowBlock Start Column
Number of BlocksThis space inserted only to align table nicely
+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Fractal Heap Block OffsetThe 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 RowThis is the row that the empty blocks start in.
Block Start ColumnThis is the column that the empty blocks start in.
Number of BlocksThis is the number of empty blocks covered by the section.
+ +\subsection subsec_fmt2_infra_sohm III.H. Disk Format: Level 1H - Shared Object Header Message Table +The shared object header message table is used to locate object header messages that are shared +between two or more object headers in the file. Shared object header messages are stored and indexed in +the file in one of two ways: indexed sequentially in a shared header message list or indexed +with a v2 B-tree. The shared messages themselves are either stored in a fractal heap (when two or more +objects share the message), or remain in an object’s header (when only one object uses the message +currently, but the message can be shared in the future). + +The shared object header message table contains a list of shared message index headers. Each +index header records information about the version of the index format, the index storage type, flags +for the message types indexed, the number of messages in the index, the address where the index resides, +and the fractal heap address if shared messages are stored there. + +Each index can be either a list or a v2 B-tree and may transition between those two forms as the number +of messages in the index varies. Each shared message record contains information used to locate the +shared message from either a fractal heap or an object header. The types of messages that can be shared +are: Dataspace, Datatype, Fill Value, Filter Pipeline and Attribute. + +The shared object header message table is pointed to from a +@ref subsubsec_fmt2_dataobject_hdr_msg_shared message in the superblock extension for a file. This +message stores the version of the table format, along with the number of index headers in the table. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Shared Object Header Message Table
bytebytebytebyte
Signature
Version for index \#0Index Type for index #0Message Type Flags for index \#0
Minimum Message Size for index \#0
List Cutoff for index \#0v2 B-tree Cutoff for index \#0
Number of Messages for index \#0This space inserted only to align table nicely

Index AddressO for index \#0


Fractal Heap AddressO for index \#0

...
...
Version for index \#N-1Index Type for index \#N-1Message Type Flags for index \#N-1
Minimum Message Size for index \#N-1
List Cutoff for index \#N-1v2 B-tree Cutoff for index \#N-1
Number of Messages for index \#N-1This space inserted only to align table nicely

Index AddressO for index \#N-1


Fractal Heap AddressO for index \#N-1

Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe 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 \#NThis is the version number for the list of shared object header message indexes and this document + describes version 0.
Index Type for index \#NThe type of index can be an unsorted list or a v2 B-tree.
Message Type Flags for index \#NThis field indicates the type of messages tracked in the index, as follows: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BitsDescription
0If set, the index tracks Dataspace Messages.
1If set, the message tracks Datatype Messages.
2If set, the message tracks Fill Value Messages.
3If set, the message tracks Filter Pipeline Messages.
4If set, the message tracks Attribute Messages.
5-15Reserved (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 \#NThis 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 \#NThis 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 \#NThis 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 \#NThe number of shared messages being tracked for the index.
Index Address for index \#NThis field is the address of the list or v2 B-tree where the index nodes reside.
Fractal Heap Address for index \#NThis field is the address of the fractal heap if shared messages are stored there.
ChecksumThis is the checksum for the table.
+ +Shared messages are indexed either with a shared message record list, described below, +or using a v2 B-tree (using record type 7). The number of records in the shared message record +list is determined in the index’s entry in the shared object header message table. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Shared Message Record List
bytebytebytebyte
Signature
Shared Message Record \#0
Shared Message Record \#1
...
Shared Message Record \#N-1
Checksum
+ + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe 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 \#NThe record for locating the shared message, either in the fractal heap for the index, or an object + header (see format for index nodes below).
ChecksumThis is the checksum for the list.
+ +The record for each shared message in an index is stored in one of the following forms: + + + + + + + + + + + + + + + + + + + + + +
Shared Message Record, for messages stored in a fractal heap
bytebytebytebyte
Message LocationThis space inserted only to align table nicely
Hash Value
Reference Count

Fractal Heap ID

+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Message LocationThis has a value of 0 indicating that the message is stored in the heap.
Hash ValueThis is the hash value for the message.
Reference CountThis is the number of times the message is used in the file.
Fractal Heap IDThis is an 8-byte fractal heap ID for the message as stored in the fractal heap for the index.
+ + + + + + + + + + + + + + + + + + + + + + + + +
Shared Message Record, for messages stored in an object header
bytebytebytebyte
Message LocationThis space inserted only to align table nicely
Hash Value
ReservedMessage TypeCreation Index

Object Header AddressO

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Message LocationThis has a value of 1 indicating that the message is stored in an object header.
Hash ValueThis is the hash value for the message.
Message TypeThis is the message type in the object header.
Creation IndexThis is the creation index of the message within the object header.
Object Header AddressThis is the address of the object header where the message is located.
+ +\section sec_fmt2_dataobject IV. Disk Format: Level 2 - Data Objects +Data objects contain the “real” user-visible information in the file. These objects compose +the scientific data and other information which are generally thought of as “data” by the +end-user. All the other information in the file is provided as a framework for storing and accessing +these data objects. + +A data object is composed of header and data information. The header information contains the +information needed to interpret the data information for the object as well as additional “metadata” +or pointers to additional “metadata” used to describe or annotate each object. + +\subsection subsec_fmt2_dataobject_hdr IV.A. Disk Format: Level 2A - Data Object Headers +The header information of an object is designed to encompass all the information about an object, except for +the data itself. This information includes the dataspace, datatype, information about how the data is stored +on disk (in external files, compressed, broken up in blocks, etc.), as well as other information used by the +library to speed up access to the data objects or maintain a file’s integrity. Information stored by user +applications as attributes is also stored in the object’s header. The header of each object is not necessarily +located immediately prior to the object’s data in the file and in fact may be located in any position in the +file. The order of the messages in an object header is not significant. + +Object headers are composed of a prefix and a set of messages. The prefix contains the information needed to +interpret the messages and a small amount of metadata about the object, and the messages contain the majority +of the metadata about the object. + +\subsection subsec_fmt2_dataobject_hdr_prefix IV.A.1 Disk Format: Level 2A1 - Data Object Headers + +\subsubsection subsubsec_fmt2_dataobject_hdr_prefix_one IV.A.1.a Version 1 Data Object Header Prefix +Header messages are aligned on 8-byte boundaries for version 1 object headers. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Version 1 Object Header
bytebytebytebyte
VersionReserved (zero)Total Number of Header Messages
Object Reference Count
Object Header Size
Header Message Type \#1Size of Header Message Data \#1
Header Message \#1 FlagsReserved (zero)

Header Message Data \#1

.
.
.
Header Message Type \#nSize of Header Message Data \#n
Header Message \#n FlagsReserved (zero)

Header Message Data \#n

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThis 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 MessagesThis 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 CountThis 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 SizeThis 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 TypeThis 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 DataThis 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 FlagsThis is a bit field with the following definition: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BitDescription
0If set, the message data is constant. This is used for messages like the datatype message of + a dataset.
1If 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 @ref + subsec_fmt2_dataobject_hdr_msg section below) and the Size of Header Message Data field contains + the size of that Shared Message.
2If set, the message should not be shared.
3If 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)
4If 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)
5If 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)
6If set, this message is shareable.
7If 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 DataThe 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 zeros to make the size a multiple of + eight.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_prefix_two IV.A.1.b Version 2 Data Object Header Prefix +Note that the “total number of messages” field has been dropped from the data object header +prefix in this version. The number of messages in the data object header is just determined by the +messages encountered in all the object header blocks. + +Note also that the fields and messages in this version of data object headers have no alignment +or padding bytes inserted - they are stored packed together. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Version 2 Object Header
bytebytebytebyte
Signature
VersionFlagsThis space inserted only to align table nicely
Access time (optional)
Modification Time (optional)
Change Time (optional)
Birth Time (optional)
Maximum \# of compact attributes (optional)Minimum \# of dense attributes (optional)
Size of Chunk \#0 (variable size)This space inserted only to align table nicely
Header Message Type \#1Size of Header Message Data \#1Header Message \#1 Flags
Header Message \#1 Creation Order (optional)This space inserted only to align table nicely

Header Message Data \#1

.
.
.
Header Message Type \#nSize of Header Message Data \#nHeader Message \#n Flags
Header Message \#n Creation Order (optional)This space inserted only to align table nicely

Header Message Data \#n

Gap (optional, variable size)
Checksum
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe 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.
VersionThis field has a value of 2 indicating version 2 of the object header.
FlagsThis field is a bit field indicating additional information about the object header. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Bit(s)Description
0-1This two bit field determines the size of the Size of Chunk \#0 field. The values are: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0The Size of Chunk \#0 field is 1 byte.
1The Size of Chunk \#0 field is 2 bytes.
2The Size of Chunk \#0 field is 4 bytes.
3The Size of Chunk \#0 field is 8 bytes.
2If set, attribute creation order is tracked.
3If set, attribute creation order is indexed.
4If set, non-default attribute storage phase change values are stored.
5If set, access, modification, change and birth times are stored.
6-7Reserved
Access TimeThis 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 TimeThis 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 TimeThis 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 TimeThis 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 attributesThis 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 attributesThis 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 \#0This 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 TypeSame format as version 1 of the object header, described above.
Size of Header Message \#n DataThis 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 FlagsSame format as version 1 of the object header, described above.
Header Message \#n Creation OrderThis 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 DataSame format as version 1 of the object header, described above.
GapA 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.
ChecksumThis is the checksum for the object header chunk.
+ +The header message types and the message data associated with them compose the critical "meta-data" about +each object. Some header messages are required for each object while others are optional. Some optional +header messages may also be repeated several times in the header itself, the requirements and number of +times allowed in the header will be noted in each header message description below. + +\subsection subsec_fmt2_dataobject_hdr_msg IV.A.2 Disk Format: Level 2A2 - Data Object Header Messages +Data object header messages are small pieces of metadata that are stored in the data object header for +each object in an HDF5 file. Data object header messages provide the metadata required to describe an +object and its contents, as well as optional pieces of metadata that annotate the meaning or purpose of +the object. + +Data object header messages are either stored directly in the data object header for the object or are +shared between multiple objects in the file. When a message is shared, a flag in the Message Flags +indicates that the actual Message Data portion of that message is stored in another location +(such as another data object header, or a heap in the file) and the Message Data field +contains the information needed to locate the actual information for the message. + +The format of shared message data is described here: + + + + + + + + + + + + + + + + + + + +
Shared Message (Version 1)
bytebytebytebyte
VersionTypeReserved (zero)
Reserved (zero)

AddressO

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number is used when there are changes in the format of a shared object message and is + described here: + + + + + + + + + + + + + +
VersionDescription
0Never used.
1Used by the library before version 1.6.1.
TypeThe type of shared message location: + + + + + + + + + +
ValueDescription
0Message stored in another object’s header (a committed message).
AddressThe address of the object header containing the message to be shared.
+ + + + + + + + + + + + + + + + + +
Shared Message (Version 2)
bytebytebytebyte
VersionTypeThis space inserted only to align table nicely

AddressO

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number is used when there are changes in the format of a shared object message and is + described here: + + + + + + + + + +
VersionDescription
2Used by the library of version 1.6.1 and after.
TypeThe type of shared message location: + + + + + + + + + +
ValueDescription
0Message stored in another object’s header (a committed message).
AddressThe address of the object header containing the message to be shared.
+ + + + + + + + + + + + + + + + + +
Shared Message (Version 3)
bytebytebytebyte
VersionTypeThis space inserted only to align table nicely
Location (variable size)
+ + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number indicates changes in the format of shared object message and is described here: + + + + + + + + + +
VersionDescription
3Used 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.
TypeThe type of shared message location: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0Message is not shared and is not shareable.
1Message stored in file’s shared object header message heap + (a shared message).
2Message stored in another object’s header (a committed message).
3Message stored is not shared, but is shareable.
LocationThis 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.
+ +The following is a list of currently defined header messages: + +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_nil IV.A.2.a. The NIL Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: NIL
Header Message Type: 0x0000
Length: Varies
Status: Optional; may be repeated.
Description:The NIL message is used to indicate a message which is to be ignored when reading the header messages + for a data object. [Possibly one which has been deleted for some reason.]
Format of Data: Unspecified
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_simple IV.A.2.b. The Dataspace Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Dataspace
Header Message Type: 0x0001
Length: Varies according to the number of dimensions, as described in the following + table.
Status: Required for dataset objects; may not be repeated.
Description:The dataspace message describes the number of dimensions (in other words, “rank”) and size + of each dimension that the data object has. This message is only used for datasets which have a + simple, rectilinear, array-like layout; datasets requiring a more complex layout are not yet supported.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Dataspace Message - Version 1
bytebytebytebyte
VersionDimensionalityFlagsReserved
Reserved
Dimension \#1 SizeL

.
.
.

Dimension \#n SizeL


Dimension \#1 Maximum SizeL

.
.
.

Dimension \#n Maximum SizeL


Permutation Index \#1L

.
.
.

Permutation Index \#nL

+\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
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)).
DimensionalityThis value is the number of dimensions that the data object has.
FlagsThis 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 SizeThis 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 SizeThis value is the maximum size of the dimension of the data as stored in the file. This value may be + the special “@ref FMT2UnlimitedDim "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 \#nThis 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 2 of the dataspace message dropped the optional permutation index value support, as it was never +implemented in the HDF5 Library: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Dataspace Message - Version 2
bytebytebytebyte
VersionDimensionalityFlagsType
Dimension \#1 SizeL

.
.
.

Dimension \#n SizeL


Dimension \#1 Maximum SizeL

.
.
.

Dimension \#n Maximum SizeL

+\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Version This value is used to determine the format of the Dataspace Message. This field should be ‘2’ + for version 2 format messages.
DimensionalityThis value is the number of dimensions that the data object has.
FlagsThis 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.
Typeindicates the type of the dataspace: + + + + + + + + + + + + + + + + + +
ValueDescription
0A scalar dataspace; in other words, a dataspace with a single, dimensionless element.
1A simple dataspace; in other words, a dataspace with a rank > 0 and an appropriate \# + of dimensions.
2A null dataspace; in other words, a dataspace with no elements.
Dimension \#n SizeThis 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 SizeThis value is the maximum size of the dimension of the data as stored in the file. This value may be + the special “@ref FMT2UnlimitedDim "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.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_linkinfo IV.A.2.c. The Link Info Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Link Info
Header Message Type: 0x002
Length: Varies
Status: Optional; may not be repeated.
Description:The link info message tracks variable information about the current state of the links for a + “new style” group’s behavior. Variable information will be stored in this + message and constant information will be stored in the @ref + subsubsec_fmt2_dataobject_hdr_msg_groupinfo message.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Link Info
bytebytebytebyte
VersionFlagsThis space inserted only to align table nicely

Maximum Creation Index (8 bytes, optional)


Fractal Heap AddressO


Address of v2 B-tree for Name IndexO


Address of v2 B-tree for Creation Order IndexO (optional)

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number for this message. This document describes version 0.
FlagsThis field determines various optional aspects of the link info message: + + + + + + + + + + + + + + + + + +
BitDescription
0If set, creation order for the links is tracked.
1If set, creation order for the links is indexed.
2-7Reserved
Maximum Creation IndexThis 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 AddressThis is the address of the fractal heap to store dense links. Each link stored in the fractal heap + is stored as a @ref subsubsec_fmt2_dataobject_hdr_msg_link.
+ 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 @ref FMT2UndefinedAddress "undefined address".
Address of v2 B-tree for Name IndexThis 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 @ref FMT2UndefinedAddress "undefined address".
Address of v2 B-tree for Creation Order IndexThis 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 @ref FMT2UndefinedAddress "undefined address".
+ This field exists if bit 1 of flags is set.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_dtmessage IV.A.2.d. The Datatype Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Datatype
Header Message Type: 0x0003
Length: Variable
Status: Required for dataset or committed datatype (formerly named datatype) + objects; may not be repeated.
Description:The datatype message defines the datatype for each element of a dataset or a common datatype for + sharing between multiple datasets. A datatype can describe an atomic type like a fixed- or + floating-point type or more complex types like a C struct (compound datatype), array (array datatype) + or C++ vector (variable-length datatype).
+ Datatype messages that are part of a dataset object do not describe how elements are related to one + another; the dataspace message is used for that purpose. Datatype messages that are part of a committed + datatype (formerly named datatype) message describe a common datatype that can be shared by multiple + datasets in the file.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + +
Datatype Message
bytebytebytebyte
Class and VersionClass Bit Field, Bits 0-7Class Bit Field, Bits 8-15Class Bit Field, Bits 16-23
Size


Properties

/
+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Class and VersionThe 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: + + + + + + + + + + + + + + + + + + + + + +
VersionDescription
0Never used
1Used by early versions of the library to encode compound datatypes with explicit array fields. + See the compound datatype description below for further details.
2Used when an array datatype needs to be encoded.
3Used when a VAX byte-ordered type needs to be encoded. Packs various other datatype classes more + efficiently also.

+ 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: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0Fixed-Point
1Floating-Point
2Time
3String
4Bit field
5Opaque
6Compound
7Reference
8Enumerated
9Variable-Length
10Array
+
Class Bit FieldsThe 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.
SizeThe size of a datatype element in bytes.
PropertiesThis 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.
+ +Class specific information for Fixed-Point Numbers (Class 0): + + + + + + + + + + + + + + + + + + + + + + +
Fixed-point Bit Field Description
BitsMeaning
0Byte Order. If zero, byte order is little-endian; otherwise, byte order is big endian.
1, 2Padding type. Bit 1 is the lo_pad type and bit 2 is the hi_pad type. If a datum has + unused bits at either end, then the lo_pad or hi_pad bit is copied to those locations.
3Signed. If this bit is set then the fixed-point number is in 2’s complement form.
4-23Reserved (zero).
+ + + + + + + + + + + + + +
+ Fixed-Point Property Descriptions +
ByteByteByteByte
Bit OffsetBit Precision
+ + + + + + + + + + + + + + +
Field NameDescription
Bit OffsetThe bit offset of the first significant bit of the fixed-point value within the datatype. The + bit offset specifies the number of bits “to the right of” the value (which are + set to the lo_pad bit value).
Bit PrecisionThe number of bits of precision of the fixed-point value within the datatype. This value, + combined with the datatype element’s size and the Bit Offset field specifies the number + of bits “to the left of” the value (which are set to the hi_pad bit value).
+ +Class specific information for Floating-Point Numbers (Class 1): + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Floating-Point Bit Field Description
BitsMeaning
0Byte Order. These two non-contiguous bits specify the “endianness” of + the bytes in the datatype element. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Bit 6Bit 0Description
00Byte order is little-endian
01Byte order is big-endian
10Reserved
11Byte order is VAX-endian
1, 2, 3Padding type. Bit 1 is the low bits pad type, bit 2 is the high bits pad type, and bit + 3 is the internal bits pad type. If a datum has unused bits at either end or between the sign bit, exponent, + or mantissa, then the value of bit 1, 2, or 3 is copied to those locations.
4-5Mantissa Normalization. This 2-bit bit field specifies how the most significant bit of + the mantissa is managed. + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0No normalization
1The most significant bit of the mantissa is always set (except for 0.0).
2The most significant bit of the mantissa is not stored, but is implied to be set.
3Reserved.
6-7Reserved (zero).
8-15Sign Location. This is the bit position of the sign bit. Bits are numbered with the least + significant bit zero.
16-23Reserved (zero).
+ + + + + + + + + + + + + + + + + + + + + + +
Floating-Point Property Description
ByteByteByteByte
Bit OffsetBit Precision
Exponent LocationExponent SizeMantissa LocationMantissa Size
Exponent Bias
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameProperty Description
Bit OffsetThe bit offset of the first significant bit of the floating-point value within the datatype. The + bit offset specifies the number of bits “to the right of” the value.
Bit PrecisionThe number of bits of precision of the floating-point value within the datatype.
Exponent LocationThe bit position of the exponent field. Bits are numbered with the least significant + bit number zero.
Exponent SizeThe size of the exponent field in bits.
Mantissa LocationThe bit position of the mantissa field. Bits are numbered with the least significant bit number + zero.
Mantissa SizeThe size of the mantissa field in bits.
Exponent BiasThe bias of the exponent field.
+ +Class specific information for Time (Class 2): + + + + + + + + + + + + + + +
Time Bit Field Description
BitsMeaning
0Byte Order. If zero, byte order is little-endian; otherwise, byte order is big endian.
1-23Reserved (zero).
+
+ + + + + + + + + + +
Time Property Description
ByteByte
Bit Precision
+
+ + + + + + + + + + +
Field NameDescription
Bit PrecisionThe number of bits of precision of the time value.
+
+ +Class specific information for Strings (Class 3): + + + + + + + + + + + + + + + + + +
String Bit Field Description
BitsMeaning
0-3Padding type. This four-bit value determines the type of padding to use for the + string. The values are: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0Null Terminate: A zero byte marks the end of the string and is guaranteed to be present after + converting a long string to a short string. When converting a short string to a long string the + value is padded with additional null characters as necessary.
1Null Pad: Null characters are added to the end of the value during conversions from short values + to long values but conversion in the opposite direction simply truncates the value.
2Space Pad: Space characters are added to the end of the value during conversions from short values + to long values but conversion in the opposite direction simply truncates the value. This is the + Fortran representation of the string.
3-15Reserved.
+
4-7Character Set. The character set used to encode the string. + + + + + + + + + + + + + + + + + +
ValueDescription
0ASCII character set encoding
1UTF-8 character set encoding
2-15Reserved
8-23Reserved (zero).
+ +There are no properties defined for the string class. + +Class specific information for Bitfields (Class 4): + + + + + + + + + + + + + + + + + + +
Bitfield Bit Field Description
BitsMeaning
0Byte Order. If zero, byte order is little-endian; otherwise, byte order is big endian.
1, 2Padding type. Bit 1 is the lo_pad type and bit 2 is the hi_pad type. If a datum has + unused bits at either end, then the lo_pad or hi_pad bit is copied to those locations.
3-23Reserved (zero).
+ + + + + + + + + + + + + +
Bit Field Property Description
ByteByteByteByte
Bit OffsetBit Precision
+ + + + + + + + + + + + + + +
Field NameDescription
Bit OffsetThe bit offset of the first significant bit of the bitfield within the datatype. The bit + offset specifies the number of bits “to the right of” the value.
Bit PrecisionThe number of bits of precision of the bit field within the datatype.
+ +Class specific information for Opaque (Class 5): + + + + + + + + + + + + + + +
Opaque Bit Field Description
BitsMeaning
0-7Length of ASCII tag in bytes.
8-23Reserved (zero).
+ + + + + + + + + + + + +
Opaque Property Description
ByteByteByteByte

ASCII Tag

+ + + + + + + + + + +
Field NameDescription
ASCII TagThis NUL-terminated string provides a description for the opaque type. It is NUL-padded to a + multiple of 8 bytes.
+ +Class specific information for Compound Types (Class 6): + + + + + + + + + + + + + + +
Compound Bit Field Description
BitsMeaning
0-15Number of Members. This field contains the number of members defined for the + compound datatype. The member definitions are listed in the Properties field of the data type + message.
16-23Reserved (zero).
+ +The Properties field of a compound datatype is a list of the member definitions of the compound datatype. +The member definitions appear one after another with no intervening bytes. The member types are described +with a (recursively) encoded datatype message. + +Note that the property descriptions are different for different versions of the datatype version. Additionally +note that the version 0 properties are deprecated and has been replaced with later encodings in +versions of the HDF5 library from the 1.4 release onward. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Compound Properties Description for Datatype Version 1
ByteByteByteByte


Name

/
Byte Offset of Member
DimensionalityReserved (zero)
Dimension Permutation
Reserved (zero)
Dimension \#1 Size (required)
Dimension \#2 Size (required)
Dimension \#3 Size (required)
Dimension \#4 Size (required)

Member Type Message

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
NameThis NUL-terminated string provides a description for the opaque type. It is NUL-padded to a + multiple of 8 bytes.
Byte Offset of MemberThis is the byte offset of the member within the datatype.
DimensionalityIf set to zero, this field indicates a scalar member. If set to a value greater than zero, + this field indicates that the member is an array of values. For array members, the size of + the array is indicated by the ‘Size of Dimension n’ field in this message.
Dimension PermutationThis field was intended to allow an array field to have its dimensions permuted, but this was + never implemented. This field should always be set to zero.
Dimension \#n SizeThis field is the size of a dimension of the array field 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.
Member Type MessageThis field is a datatype message describing the datatype of the member.
+ + + + + + + + + + + + + + + + + + +
Compound Properties Description for Datatype Version 2
ByteByteByteByte

Name

Byte Offset of Member

Member Type Message

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
NameThis NUL-terminated string provides a description for the opaque type. It is NUL-padded to a multiple + of 8 bytes.
Byte Offset of MemberThis is the byte offset of the member within the datatype.
Member Type MessageThis field is a datatype message describing the datatype of the member.
+ + + + + + + + + + + + + + + + + + +
Compound Properties Description for Datatype Version 3
ByteByteByteByte

Name

Byte Offset of Member

Member Type Message

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
NameThis NUL-terminated string provides a description for the opaque type. It is not NUL-padded to a + multiple of 8 bytes.
Byte Offset of MemberThis is the byte offset of the member within the datatype. The field size is the minimum number of bytes + necessary, based on the size of the datatype element. For example, a datatype element size of less than + 256 bytes uses a 1 byte length, a datatype element size of 256-65535 bytes uses a 2 byte length, and + so on.
Member Type MessageThis field is a datatype message describing the datatype of the member.
+ +Class specific information for Reference (Class 7): + + + + + + + + + + + + + + +
Reference Bit Field Description
BitsMeaning
0-3Type. This four-bit value contains the type of reference described. The values defined are: + + + + + + + + + + + + + + + + + +
ValueDescription
0Object Reference: A reference to another object in this HDF5 file.
1Dataset Region Reference: A reference to a region within a dataset in this HDF5 file.
2-15Reserved
+
4-23Reserved (zero).
+ +There are no properties defined for the reference class. + +Class specific information for Enumeration (Class 8): + + + + + + + + + + + + + + +
Enumeration Bit Field Description
BitsMeaning
0-15Number of Members. The number of name/value pairs defined for the enumeration type.
16-23Reserved (zero).
+ + + + + + + + + + + + + + + + + + +
Enumeration Property Description for Datatype Versions 1 & 2
ByteByteByteByte

Base Type
/

Names


Values

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
Base TypeEach enumeration type is based on some parent type, usually an integer. The information + for that parent type is described recursively by this field.
NamesThe name for each name/value pair. Each name is stored as a null terminated ASCII string + in a multiple of eight bytes. The names are in no particular order.
ValuesThe list of values in the same order as the names. The values are packed (no inter-value + padding) and the size of each value is determined by the parent type.
+ + + + + + + + + + + + + + + + + + +
Enumeration Property Description for Datatype Versions 3
ByteByteByteByte

Base Type
/

Names


Values

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
Base TypeEach enumeration type is based on some parent type, usually an integer. The information + for that parent type is described recursively by this field.
NamesThe name for each name/value pair. Each name is stored as a null terminated ASCII string, + not padded to a multiple of eight bytes. The names are in no particular order.
ValuesThe list of values in the same order as the names. The values are packed (no inter-value + padding) and the size of each value is determined by the parent type.
+ +Class specific information for Variable-Length (Class 9): + + + + + + + + + + + + + + + + + + + + + + +
Variable-Length Bit Field Description
BitsMeaning
0-3Type. This four-bit value contains the type of variable-length datatype described. + The values defined are: + + + + + + + + + + + + + + + + + +
ValueDescription
0Sequence: A variable-length sequence of any datatype. Variable-length sequences do not + have padding or character set information.
1String: A variable-length sequence of characters. Variable-length strings have padding and + character set information.
2-15Reserved
4-7Padding type. (variable-length string only). This four-bit value determines the + type of padding used for variable-length strings. The values are the same as for the string padding + type, as follows: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
00 Null terminate: A zero byte marks the end of a string and is guaranteed to be present after + converting a long string to a short string. When converting a short string to a long string, + the value is padded with additional null characters as necessary.
1Null pad: Null characters are added to the end of the value during conversion from a short string to + a longer string. Conversion from a long string to a shorter string simply truncates the value.
2Space pad: Space characters are added to the end of the value during conversion from a short string + to a longer string. Conversion from a long string to a shorter string simply truncates the value. + This is the Fortran representation of the string.
3-15Reserved
+ This value is set to zero for variable-length sequences.
8-11Character Set. (variable-length string only) This four-bit value specifies the + character set to be used for encoding the string: + + + + + + + + + + + + + + + + + +
ValueDescription
0ASCII character set encoding.
1UTF-8 character set encoding.
2-15Reserved
+ This value is set to zero for variable-length sequences.
12-23Reserved (zero).
+ + + + + + + + + + + + +
Variable-Length Property Description
ByteByteByteByte

Base Type

+ + + + + + + + + + +
Field NameDescription
Base TypeEach variable-length type is based on some parent type. The information for that parent + type is described recursively by this field.
+ +Class specific information for Array (Class 10): + +There are no bit fields defined for the array class. + +Note that the dimension information defined in the property for this datatype class is independent of +dataspace information for a dataset. The dimension information here describes the dimensionality of the +information within a data element (or a component of an element, if the array datatype is nested within +another datatype) and the dataspace for a dataset describes the location of the elements in a dataset. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Array Property Description for Datatype Version 2
ByteByteByteByte
DimensionalityReserved (zero)
Dimension \#1 Size
.
.
.
Dimension \#n Size
Permutation Index \#1
.
.
.
Permutation Index \#n

Base Type

+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
DimensionalityThis value is the number of dimensions that the array has.
Dimension \#n SizeThis value is the size of the dimension of the array 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.
Permutation Index \#nThis value is the index permutation used to map each dimension from the canonical representation + to an alternate axis for each dimension. Currently, dimension permutations are not supported and + these indices should be set to the index position minus one (i.e. the first dimension should be + set to 0, the second dimension should be set to 1, and so on.)
Base TypeEach array type is based on some parent type. The information for that parent type is described + recursively by this field.
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Array Property Description for Datatype Version 3
ByteByteByteByte
DimensionalityThis space inserted only to align table nicely
Dimension \#1 Size
.
.
.
Dimension \#n Size

Base Type

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
DimensionalityThis value is the number of dimensions that the array has.
Dimension \#n SizeThis value is the size of the dimension of the array 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.
Base TypeEach array type is based on some parent type. The information for that parent type is described + recursively by this field.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_ofvmessage IV.A.2.e. Data Storage - Fill Value (Old) Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Fill Value (old)
Header Message Type: 0x0004
Length: Varies
Status: Optional; may not be repeated.
Description:The fill value message stores a single data value which is returned to the application when an + uninitialized data element is read from a dataset. The fill value is interpreted with the same + datatype as the dataset. If no fill value message is present then a fill value of all zero bytes + is assumed.
+ This fill value message is deprecated in favor of the “new” fill value message (Message + Type 0x0005) and is only written to the file for forward compatibility with versions of the HDF5 + Library before the 1.6.0 version. Additionally, it only appears for datasets with a user-defined + fill value (as opposed to the library default fill value or an explicitly set “undefined” + fill value).
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + +
Fill Value Message (Old)
bytebytebytebyte
Size (4 bytes)

Fill Value (optional, variable size)

+
+ + + + + + + + + + + + + +
Field NameDescription
SizeThis is the size of the Fill Value field in bytes.
Fill ValueThe fill value. The bytes of the fill value are interpreted using the same datatype as for the dataset.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_fvmessage IV.A.2.f. The Data Storage - Fill Value Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Fill Value
Header Message Type: 0x0005
Length: Varies
Status: Required for dataset objects; may not be repeated.
Description:The fill value message stores a single data value which is returned to the application when an + uninitialized data element is read from a dataset. The fill value is interpreted with the same + datatype as the dataset.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + +
Fill Value Message - Versions 1 & 2
bytebytebytebyte
VersionSpace Allocation TimeFill Value Write TimeFill Value Defined
Size (optional)

Fill Value (optional, variable size)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number information is used for changes in the format of the fill value message and + is described here: + + + + + + + + + + + + + + + + + + + + + +
VersionDescription
0Never used
1Initial version of this message.
2In this version, the Size and Fill Value fields are only present if the Fill Value Defined + field is set to 1.
3This version packs the other fields in the message more efficiently than version 2.
+
Space Allocation TimeWhen the storage space for the dataset’s raw data will be allocated. The allowed values are: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0Not used
1Early allocation. Storage space for the entire dataset should be allocated in the file + when the dataset is created.
2Late allocation. Storage space for the entire dataset should not be allocated until the + dataset is written to.
3Incremental 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 TimeAt 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: + + + + + + + + + + + + + + + + + +
ValueDescription
0On allocation. The fill value is always written to the raw data storage when the storage + space is allocated.
1Never. The fill value should never be written to the raw data storage.
2Fill 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 DefinedThis 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 field.
SizeThis 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 ValueThe 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.
+ + + + + + + + + + + + + + + + + + + + + +
Fill Value Message - Versions 3
bytebytebytebyte
VersionFlagsFill Value Write TimeThis space inserted only to align table nicely
Size (optional)

Fill Value (optional, variable size)

+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number information is used for changes in the format of the fill value message and + is described here: + + + + + + + + + + + + + + + + + + + + + +
VersionDescription
0Never used
1Initial version of this message.
2In this version, the Size and Fill Value fields are only present if the Fill Value Defined + field is set to 1.
3This version packs the other fields in the message more efficiently than version 2.
+
FlagsWhen the storage space for the dataset’s raw data will be allocated. The allowed values are: + + + + + + + + + + + + + + + + + + + + + + + + + +
BitsDescription
0-1Space Allocation Time, with the same values as versions 1 and 2 of the message.
2-3Fill Value Write Time, with the same values as versions 1 and 2 of the message.
4Fill Value Undefined, indicating that the fill value has been marked as “undefined” + for this dataset. Bits 4 and 5 cannot both be set.
5Fill Value Defined, with the same values as versions 1 and 2 of the message. Bits 4 and 5 + cannot both be set.
6-7Reserved (zero).
SizeThis 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 ValueThe 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.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_link IV.A.2.g. The Link Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Link
Header Message Type: 0x0006
Length: Varies
Status: Optional; may be repeated.
Description:This message encodes the information for a link in a group’s object header, when the group is + storing its links “compactly”, or in the group’s fractal heap, when the group is + storing its links “densely”.
+ A group is storing its links compactly when the fractal heap address in the + @ref subsubsec_fmt2_dataobject_hdr_msg_linkinfo is set to the + @ref FMT2UndefinedAddress "undefined address" value.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Link Message
bytebytebytebyte
VersionFlagsLink type (optional)This space inserted only to align table nicely

Creation Order (8 bytes, optional)

Link Name Character Set (optional)Length of Link Name (variable size)This space inserted only to align table nicely
Link Name (variable size)

Link Information (variable size)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number for this message. This document describes version 1.
FlagsThis field contains information about the link and controls the presence of other fields below. + + + + + + + + + + + + + + + + + + + + + + + + + +
BitsDescription
0-1Determines the size of the Length of Link Name field. + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0The size of the Length of Link Name field is 1 byte.
1The size of the Length of Link Name field is 2 bytes.
2The size of the Length of Link Name field is 4 bytes.
3The size of the Length of Link Name field is 8 bytes.
2Creation 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.
3Link 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.
4Link 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-7Reserved (zero).
Link typeThis is the link class type and can be one of the following values: + + + + + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0A hard link (should never be stored in the file)
1A soft link.
2-63Reserved for future HDF5 internal use.
64An external link.
65-255Reserved, but available for user-defined link types.
+ This field is present if bit 3 of Flags is set.
Creation OrderThis 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 SetThis is the character set for encoding the link’s name: + + + + + + + + + + + + + +
ValueDescription
0ASCII character set encoding (this should never be stored in the file)
1UTF-8 character set encoding
+ This field is present if bit 4 of Flags is set.
Length of link nameThis is the length of the link’s name. The size of this field depends on bits 0 and 1 of Flags.
Link nameThis is the name of the link, non-NULL terminated.
Link informationThe 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.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_external IV.A.2.h. The Data Storage - External Data Files Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: External Data Files
Header Message Type: 0x0007
Length: Varies
Status: Optional; may not be repeated.
Description:The external data storage message indicates that the data for an object is stored outside the HDF5 + file. The filename of the object is stored as a Universal Resource Location (URL) of the actual + filename containing the data. An external file list record also contains the byte offset of the + start of the data within the file and the amount of space reserved in the file for that data.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + +
External File List Message
bytebytebytebyte
VersionReserved (zero)
Allocated SlotsUsed Slots

Heap AddressO


Slot Definitions...

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number information is used for changes in the format of External Data Storage Message + and is described here: + + + + + + + + + + + + + +
VersionDescription
0Never used.
1The current version used by the library.
Allocated SlotsThe 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 SlotsThe number of initial slots which contain valid information.
Heap AddressThis is the address of a local name 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 DefinitionsThe slot definitions are stored in order according to the array addresses they represent.
+ + + + + + + + + + + + + + + + + + +
External File List Slot
bytebytebytebyte

Name Offset in Local HeapL


File Offset in External Data FileL


Data Size in External FileL

+\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + + + + + +
Field NameDescription
Name Offset in Local HeapThe 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 FileThis 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 FileThis 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 zeros past the end of the file without failing.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_layout IV.A.2.i. The Data Storage - Layout Message + + + + + + + + + + + + + + + + + + + +
Header Message Name: Data Storage - Layout
Header Message Type: 0x0008
Length: Varies
Status: Required for datasets; may not be repeated.
Description: Data layout describes how the elements of a multi-dimensional array + are stored in the HDF5 file. Three types of data layout are supported: +
    +
  1. Contiguous: The array is stored in one contiguous area of the file. This layout requires that the + size of the array be constant: data manipulations such as chunking, compression, checksums or encryption + are not permitted. The message stores the total storage size of the array. The offset of an element from + the beginning of the storage area is computed as in a C array.
    2. +
  2. Chunked: The array domain is regularly decomposed into chunks, and each chunk is allocated and stored + separately. This layout supports arbitrary element traversals, compression, encryption, and checksums + (these features are described in other messages). The message stores the size of a chunk instead of the + size of the entire array; the size of the entire array can be calculated by traversing the B-tree that + stores the chunk addresses.
    3. +
  3. Compact: The array is stored in one contiguous block, as part of this object header messagei.
    4. +
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Data Layout Message (Versions 1 and 2)
bytebytebytebyte
VersionDimensionalityLayout ClassReserved (zero)
Reserved (zero)

Data AddressO (optional)

Dimension 0 Size
Dimension 1 Size
...
Dataset Element Size (optional)
Compact Data Size (optional)

Compact Data...(variable size, optional)

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number information is used for changes in the format of the data layout message and + is described here: + + + + + + + + + + + + + + + + + +
VersionDescription
0Never used.
1Used by version 1.4 and before of the library to encode layout information. Data space is + always allocated when the data set is created.
2Used by version 1.6.x of the library to encode layout information. Data space is allocated + only when it is necessary.
DimensionalityAn array has a fixed dimensionality. This field specifies the number of dimension size fields later + in the message. The value stored for chunked storage is 1 greater than the number of dimensions in + the dataset’s dataspace. For example, 2 is stored for a 1 dimensional dataset.
Layout ClassThe layout class specifies the type of storage for the data and how the other fields of the layout + message are to be interpreted. + + + + + + + + + + + + + + + + + +
ValueDescription
0Compact Storage
1Contiguous Storage
2Chunked Storage
Data AddressFor contiguous storage, this is the address of the raw data in the file. For chunked storage this is + the address of the v1 B-tree that is used to look up the addresses of the chunks. This field is not present + for compact storage. If the version for this message is greater than 1, the address may have the + @ref FMT2UndefinedAddress "undefined address" value, to indicate that storage has not yet been + allocated for this array.
Dimension \#n SizeFor contiguous and compact storage the dimensions define the entire size of the array while for chunked storage + they define the size of a single chunk. In all cases, they are in units of array elements (not bytes). The + first dimension stored in the list of dimensions is the slowest changing dimension and the last dimension + stored is the fastest changing dimension.
Dataset Element SizeThe size of a dataset element, in bytes. This field is only present for chunked storage.
Compact Data SizeThis field is only present for compact data storage. It contains the size of the raw data for the + dataset array, in bytes.
Compact DataThis field is only present for compact data storage. It contains the raw data for the dataset + array.
+ +Version 3 of this message re-structured the format into specific properties that are required for each layout class. + + + + + + + + + + + + + + + + +
Data Layout Message (Version 3)
bytebytebytebyte
VersionLayout ClassThis space inserted only to align table nicely

Properties (variable size)

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number information is used for changes in the format of layout message and is + described here:

+ + + + + + + + + +
VersionDescription
3Used by the version 1.6.3 and later of the library to store properties for each layout class.
Layout ClassThe layout class specifies how the other fields of the layout message are to be interpreted. + + + + + + + + + + + + + + + + + +
ValueDescription
0Compact Storage
1Contiguous Storage
2Chunked Storage
PropertiesThis variable-sized field encodes information specific to each layout class and is described below. If + there is no property information specified for a layout class, the size of this field is zero bytes.
+ +Class-specific information for compact layout (Class 0): (Note: The dimensionality information is in +the Dataspace message) + + + + + + + + + + + + + + + + +
Compact Storage Property Description
bytebytebytebyte
SizeThis space inserted only to align table nicely

Raw Data...(variable size)

+ + + + + + + + + + + + + + +
Field NameDescription
SizeThis field contains the size of the raw data for the dataset array, in bytes.
Raw DataThis field contains the raw data for the dataset array.
+ +Class-specific information for contiguous layout (Class 1): (Note: The dimensionality information is +in the Dataspace message) + + + + + + + + + + + + + + + +
Contiguous Storage Property Description
bytebytebytebyte

AddressO


SizeL

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + +
Field NameDescription
AddressThis is the address of the raw data in the file. The address may have the + @ref FMT2UndefinedAddress "undefined address" value, to indicate that storage has not + yet been allocated for this array.
SizeThis field contains the size allocated to store the raw data, in bytes.
+ +Class-specific information for chunked layout (Class 2): + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Chunked Storage Property Description
bytebytebytebyte
DimensionalityThis space inserted only to align table nicely

AddressO

Dimension 0 Size
Dimension 1 Size
...
Dimension \#n Size
Dataset Element Size
+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Dimensionality>A chunk has a fixed dimensionality. This field specifies the number of dimension size fields + later in the message.
AddressThis is the address of the v1 B-tree that is used to look up the addresses of the chunks that + actually store portions of the array data. The address may have the + @ref FMT2UndefinedAddress "undefined address" value, to indicate + that storage has not yet been allocated for this array.
Dimension \#n SizeThese values define the dimension size of a single chunk, in units of array elements (not bytes). + The first dimension stored in the list of dimensions is the slowest changing dimension and the + last dimension stored is the fastest changing dimension.
Dataset Element SizeThe size of a dataset element, in bytes.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_bogus IV.A.2.j. The Bogus Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Bogus
Header Message Type: 0x0009
Length: 4 bytes
Status: For testing only; should never be stored in a valid file.
Description:This message is used for testing the HDF5 Library’s response to an “unknown” + message type and should never be encountered in a valid HDF5 file.
Format of Data: See the tables below.
+ + + + + + + + + + + + +
Bogus Message
bytebytebytebyte
Bogus Value
+ + + + + + + + + + +
Field NameDescription
Bogus ValueThis value should always be: 0xdeadbeef.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_groupinfo IV.A.2.k. The Group Info Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Group Info
Header Message Type: 0x000A
Length: Varies
Status: Optional; may not be repeated.
Description:This message stores information for the constants defining a “new style” group’s + behavior. Constant information will be stored in this message and variable information will be stored + in the @ref subsubsec_fmt2_dataobject_hdr_msg_linkinfo message.
+ Note: the “estimated entry” information below is used when determining the size of the + object header for the group when it is created.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + +
Group Info Message
bytebytebytebyte
VersionFlagsLink Phase Change: Maximum Compact Value (optional)
Link Phase Change: Minimum Dense Value (optional)Estimated Number of Entries (optional)
Estimated Link Name Length of Entries (optional)This space inserted only to align table nicely
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number for this message. This document describes version 0.
FlagsThis is the group information flag with the following definition: + + + + + + + + + + + + + + + + + +
BitDescription
0If set, link phase change values are stored.
1If set, the estimated entry information is non-default + and is stored.
2-7Reserved
Link Phase Change: Maximum Compact ValueThe is the maximum number of links to store “compactly” (in the group’s object header).
+ This field is present if bit 0 of Flags is set.
Link Phase Change: Minimum Dense ValueThis is the minimum number of links to store “densely” (in the group’s fractal + heap). The fractal heap’s address is located in the @ref subsubsec_fmt2_dataobject_hdr_msg_linkinfo + message.
+ This field is present if bit 0 of Flags is set.
Estimated Number of EntriesThis is the estimated number of entries in groups. If this field is not present, the default value of + 4 will be used for the estimated number of group entries.
+ This field is present if bit 1 of Flags is set.
Estimated Link Name Length of EntriesThis is the estimated length of entry name. If this field is not present, the default value of + 8 will be used for the estimated link name length of group entries.
+ This field is present if bit 1 of Flags is set.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_filter IV.A.2.l. The Data Storage - Filter Pipeline Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Data Storage - Filter Pipeline
Header Message Type: 0x000B
Length: Varies
Status: Optional; may not be repeated.
Description:This message describes the filter pipeline which should be applied to the data stream by providing filter + identification numbers, flags, a name, and client data.
+ This message may be present in the object headers of both dataset and group objects. For datasets, it + specifies the filters to apply to raw data. For groups, it specifies the filters to apply to the + group’s fractal heap. Currently, only datasets using chunked data storage use the filter pipeline + on their raw data.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + +
Filter Pipeline Message - Version 1
bytebytebytebyte
VersionNumber of FiltersReserved (zero)
Reserved (zero)

Filter Description List (variable size)

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number for this message. This table describes version 1.
Number of FiltersThe total number of filters described in this message. The maximum possible number of filters in a + message is 32.
Filter Description ListA description of each filter. A filter description appears in the next table.
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Filter Description
bytebytebytebyte
Filter IdentificationName Length
FlagsNumber of Values for Client Data

Name (variable size, optional)


Client Data (variable size, optional)

Padding (variable size, optional)
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Filter Identification ValueThis value, often referred to as a filter identifier, is designed to be a unique identifier for + the filter. Values from zero through 32,767 are reserved for filters supported by The HDF Group + in the HDF5 library and for filters requested and supported by third parties. Filters supported + by The HDF Group are documented immediately below. Information on 3rd-party filters can be found + at The HDF Group’s + Registered Filters page.
+ 1
To request a filter identifier, + please contact The HDF Group’s Help Desk at HDF Help Desk. + You will be asked to provide the following information: +
    +
  1. Contact information for the developer requesting the new identifier
    2. +
  2. A short description of the new filter
    3. +
  3. Links to any relevant information, including licensing information
    4. +

+ Values from 32768 to 65535 are reserved for non-distributed uses (for example, internal company usage) + or for application usage when testing a feature. The HDF Group does not track or document the use of + the filters with identifiers from this range.
+ The filters currently in library version 1.8.0 are listed below: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IdentificationNameDescription
0N/AReserved
1deflateGZIP deflate compression
2shuffleData element shuffling
3fletcher32Fletcher32 checksum
4szipSZIP compression
5nbitN-bit packing
6scaleoffsetScale and offset encoded values
Name LengthEach filter has an optional null-terminated ASCII name and this field holds the length of the name + including the null termination padded with nulls to be a multiple of eight. If the filter has no name + then a value of zero is stored in this field.
FlagsThe flags indicate certain properties for a filter. The bit values defined so far are: + + + + + + + + + + + + + +
ValueDescription
0If set then the filter is an optional filter. During output, if an optional filter fails it will be + silently skipped in the pipeline.
1-15Reserved (zero)
Number of Client Data ValuesEach filter can store integer values to control how the filter operates. The number of entries + in the Client Data array is stored in this field.
NameIf the Name Length field is non-zero then it will contain the size of this field, padded + to a multiple of eight. This field contains a null-terminated, ASCII character string to serve as + a comment/name for the filter.
Client DataThis is an array of four-byte integers which will be passed to the filter function. The Client Data + Number of Values determines the number of elements in the array.
PaddingFour bytes of zeroes are added to the message at this point if the Client Data Number of Values field + contains an odd number.
+\anchor FMT2Footnote1Change 1 If you are reading an earlier version of this document, this +link may have changed. If the link does not work, use the latest version of this document on +The HDF Group’s github website, +HDF5 File Format Specification; the link there will always be correct. + + + + + + + + + + + + + + + + + +
Filter Pipeline Message - Version 2
bytebytebytebyte
VersionNumber of FiltersThis space inserted only to align table nicely

Filter Description List (variable size)

+ + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number for this message. This table describes version 2.
Number of FiltersThe total number of filters described in this message. The maximum possible number of filters in a + message is 32.
Filter Description ListA description of each filter. A filter description appears in the next table.
+ + + + + + + + + + + + + + + + + + + + + + + +
Filter Description
bytebytebytebyte
Filter IdentificationName Length (optional)
FlagsNumber Client Data Values

Name (variable size, optional)


Client Data (variable size, optional)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
Filter Identification ValueThis value, often referred to as a filter identifier, is designed to be a unique identifier for + the filter. Values from zero through 32,767 are reserved for filters supported by The HDF Group + in the HDF5 library and for filters requested and supported by third parties. Filters supported + by The HDF Group are documented immediately below. Information on 3rd-party filters can be found + at The HDF Group’s + Registered Filters page.
+ 1
To request a filter identifier, + please contact The HDF Group’s Help Desk at HDF Help Desk. + You will be asked to provide the following information: +
    +
  1. Contact information for the developer requesting the new identifier
    2. +
  2. A short description of the new filter
    3. +
  3. Links to any relevant information, including licensing information
    4. +

+ Values from 32768 to 65535 are reserved for non-distributed uses (for example, internal company usage) + or for application usage when testing a feature. The HDF Group does not track or document the use of + the filters with identifiers from this range.
+ The filters currently in library version 1.8.0 are listed below: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IdentificationNameDescription
0N/AReserved
1deflateGZIP deflate compression
2shuffleData element shuffling
3fletcher32Fletcher32 checksum
4szipSZIP compression
5nbitN-bit packing
6scaleoffsetScale and offset encoded values
Name LengthEach filter has an optional null-terminated ASCII name and this field holds the length of the name + including the null termination padded with nulls to be a multiple of eight. If the filter has no name + then a value of zero is stored in this field.
+ Filters with IDs less than 256 (in other words, filters that are defined in this format documentation) + do not store the Name Length or Name fields.
FlagsThe flags indicate certain properties for a filter. The bit values defined so far are: + + + + + + + + + + + + + +
ValueDescription
0If set then the filter is an optional filter. During output, if an optional filter fails it will be + silently skipped in the pipeline.
1-15Reserved (zero)
Number of Client Data ValuesEach filter can store integer values to control how the filter operates. The number of entries + in the Client Data array is stored in this field.
NameIf the Name Length field is non-zero then it will contain the size of this field, padded + to a multiple of eight. This field contains a null-terminated, ASCII character string to serve as + a comment/name for the filter.
Client DataThis is an array of four-byte integers which will be passed to the filter function. The Client Data + Number of Values determines the number of elements in the array.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_attribute IV.A.2.m. The Attribute Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Attribute
Header Message Type: 0x000C
Length: Varies
Status: Optional; may be repeated.
Description:The Attribute message is used to store objects in the HDF5 file which are used as attributes, + or “metadata” about the current object. An attribute is a small dataset; it has a name, + a datatype, a dataspace, and raw data. Since attributes are stored in the object header, they should + be relatively small (in other words, less than 64KB). They can be associated with any type of object + which has an object header (groups, datasets, or committed (named) datatypes).
+ In 1.8.x versions of the library, attributes can be larger than 64KB. See the + “ @ref subsec_attribute_special ” section of the Attributes chapter in + the @ref UG for more information.
+ Note: Attributes on an object must have unique names: the HDF5 Library currently enforces this by + causing the creation of an attribute with a duplicate name to fail. Attributes on different + objects may have the same name, however.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Attribute Message (Version 1)
bytebytebytebyte
VersionReserved (zero)Name Size
Datatype SizeDataspace Size

Name (variable size)


Datatype (variable size)


Dataspace (variable size)


Data (variable size)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number information is used for changes in the format of the attribute message and is + described here: + + + + + + + + + + + + + +
VersionDescription
0Never used.
1Used by the library before version 1.6 to encode attribute message. This version does not + support shared datatypes.
Name SizeThe length of the attribute name in bytes including the null terminator. Note that the + Name field below may contain additional padding not represented by this field.
Datatype SizeThe length of the datatype description in the Datatype field below. Note that the + Datatype field may contain additional padding not represented by this field.
Dataspace SizeThe length of the dataspace description in the Dataspace field below. Note that the + Dataspace field may contain additional padding not represented by this field.
NameThe null-terminated attribute name. This field is padded with additional null characters to make it a + multiple of eight bytes.
TypeThe datatype description follows the same format as described for the datatype object header message. + This field is padded with additional zero bytes to make it a multiple of eight bytes.
SpaceThe dataspace description follows the same format as described for the dataspace object header message. + This field is padded with additional zero bytes to make it a multiple of eight bytes.
DataThe raw data for the attribute. The size is determined from the datatype and dataspace descriptions. + This field is not padded with additional bytes.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Attribute Message (Version 2)
bytebytebytebyte
VersionFlagsName Size
Datatype SizeDataspace Size

Name (variable size)


Datatype (variable size)


Dataspace (variable size)


Data (variable size)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number information is used for changes in the format of the attribute message and is + described here: + + + + + + + + + +
VersionDescription
2Used by the library of version 1.6.x and after to encode attribute messages. This version + supports shared datatypes. The fields of name, datatype, and dataspace are not padded with + additional bytes of zero.
Flags>This bit field contains extra information about interpreting the attribute message: + + + + + + + + + + + + + +
BitDescription
0If set, datatype is shared.
1If set, dataspace is shared.
Name Size>The length of the attribute name in bytes including the null terminator.
Datatype SizeThe length of the datatype description in the Datatype field below.
Dataspace SizeThe length of the dataspace description in the Dataspace field below.
NameThe null-terminated attribute name. This field is not padded with additional bytes.
DatatypeThe datatype description follows the same format as described for the datatype object + header message.
+ If the Flag field indicates this attribute’s datatype is shared, this field will + contain a “shared message” encoding instead of the datatype encoding.
+ This field is not padded with additional bytes.
DataspaceThe dataspace description follows the same format as described for the dataspace object + header message.
+ If the Flag field indicates this attribute’s dataspace is shared, this field will + contain a “shared message” encoding instead of the dataspace encoding.
+ This field is not padded with additional bytes.
DataThe raw data for the attribute. The size is determined from the datatype and dataspace + descriptions.
+ This field is not padded with additional zero bytes.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Attribute Message (Version 3)
bytebytebytebyte
VersionFlagsName Size
Datatype SizeDataspace Size
Name Character Set EncodingThis space inserted only to align table nicely

Name (variable size)


Datatype (variable size)


Dataspace (variable size)


Data (variable size)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number information is used for changes in the format of the attribute message and is + described here: + + + + + + + + + +
VersionDescription
2Used by the library of version 1.8.x and after to encode attribute messages. This version + supports attributes with non-ASCII names.
Flags>This bit field contains extra information about interpreting the attribute message: + + + + + + + + + + + + + +
BitDescription
0If set, datatype is shared.
1If set, dataspace is shared.
Name Size>The length of the attribute name in bytes including the null terminator.
Datatype SizeThe length of the datatype description in the Datatype field below.
Dataspace SizeThe length of the dataspace description in the Dataspace field below.
Name Character Set EncodingThe character set encoding for the attribute’s name: + + + + + + + + + + + + + +
ValueDescription
0ASCII character set encoding
1UTF-8 character set encoding
NameThe null-terminated attribute name. This field is not padded with additional bytes.
DatatypeThe datatype description follows the same format as described for the datatype object + header message.
+ If the Flag field indicates this attribute’s datatype is shared, this field will + contain a “shared message” encoding instead of the datatype encoding.
+ This field is not padded with additional bytes.
DataspaceThe dataspace description follows the same format as described for the dataspace object + header message.
+ If the Flag field indicates this attribute’s dataspace is shared, this field will + contain a “shared message” encoding instead of the dataspace encoding.
+ This field is not padded with additional bytes.
DataThe raw data for the attribute. The size is determined from the datatype and dataspace + descriptions.
+ This field is not padded with additional zero bytes.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_comment IV.A.2.n. The Object Comment Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Object Comment
Header Message Type: 0x000D
Length: Varies
Status: Optional; may not be repeated.
Description:The object comment is designed to be a short description of an object. An object comment is a sequence + of non-zero (\0) ASCII characters with no other formatting included by the library.
Format of Data: See the tables below.
+ + + + + + + + + + + + +
Name Message
bytebytebytebyte

Comment (variable size)

+
+ + + + + + + + + + +
Field NameDescription
NameA null terminated ASCII character string.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_omodified IV.A.2.o. The Object Modification Time (Old) Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Object Modification Time (Old)
Header Message Type: 0x000E
Length: Fixed
Status: Optional; may not be repeated.
Description:The object modification date and time is a timestamp which indicates (using ISO-8601 date and + time format) the last modification of an object. The time is updated when any object header + message changes according to the system clock where the change was posted. All fields of this + message should be interpreted as coordinated universal time (UTC).
+ This modification time message is deprecated in favor of the “new” + @ref subsubsec_fmt2_dataobject_hdr_msg_mod message and is no longer written to the file in + versions of the HDF5 Library after the 1.6.0 version.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + + +
Modification Time Message
bytebytebytebyte
Year
MonthDay of Month
HourMinute
SecondReserved
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
YearThe four-digit year as an ASCII string. For example, 1998.
MonthThe month number as a two digit ASCII string where January is 01 and December is + 12.
Day of MonthThe day number within the month as a two digit ASCII string. The first day of the month is + 01.
HourThe hour of the day as a two digit ASCII string where midnight is 00 and 11:00pm + is 23.
MinuteThe minute of the hour as a two digit ASCII string where the first minute of the hour is + 00 and the last is 59.
SecondThe second of the minute as a two digit ASCII string where the first second of the minute is + 00 and the last is 59.
ReservedThis field is reserved and should always be zero.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_shared IV.A.2.p. The Shared Message Table Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Shared Message Table
Header Message Type: 0x000F
Length: Fixed
Status: Optional; may not be repeated.
Description:This message is used to locate the table of shared object header message (SOHM) indexes. Each + index consists of information to find the shared messages from either the heap or object header. + This message is only found in the superblock extension.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + +
Shared Message Table Message
bytebytebytebyte
VersionThis space inserted only to align table nicely

Shared Object Header Message Table AddressO

Number of IndicesThis space inserted only to align table nicely
+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number for this message. This document describes version 0.
Shared Object Header Message Table AddressThis field is the address of the master table for shared object header message indexes.
Number of IndicesThis field is the number of indices in the master table.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_continuation IV.A.2.q. The Object Header Continuation Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Object Header Continuation
Header Message Type: 0x0010
Length: Fixed
Status: Optional; may be repeated.
Description:The object header continuation is the location in the file of a block containing more header messages + for the current data object. This can be used when header blocks become too large or are likely to + change over time.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + +
Object Header Continuation Message
bytebytebytebyte

OffsetO


LengthL

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + +
Field NameDescription
OffsetThis value is the address in the file where the header continuation block is located.
LengthThis value is the length in bytes of the header continuation block in the file.
+ +The format of the header continuation block that this message points to depends on the version of the +object header that the message is contained within. + +Continuation blocks for version 1 object headers have no special formatting information; they are +merely a list of object header message info sequences (type, size, flags, reserved bytes and data for +each message sequence). See the description of @ref subsubsec_fmt2_dataobject_hdr_prefix_one. + +Continuation blocks for version 2 object headers do have special formatting information as +described here (see also the description of @ref subsubsec_fmt2_dataobject_hdr_prefix_two): + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Version 2 Object Header Continuation Block
bytebytebytebyte
Signature
Header Message Type \#1Size of Header Message Data \#1Header Message \#1 Flags
Header Message \#1 Creation Order (optional)This space inserted only to align table nicely

Header Message Data \#1

.
.
.
Header Message Type \#nSize of Header Message Data \#nHeader Message \#n Flags
Header Message \#n Creation Order (optional)This space inserted only to align table nicely

Header Message Data \#n

Gap (optional, variable size)
Checksum
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
SignatureThe ASCII character string “OCHK” is used to indicate the + beginning of an object header continuation block. This gives file consistency checking + utilities a better chance of reconstructing a damaged file.
Header Message \#n TypeSame format as version 1 of the object header, described above.
Size of Header Message \#n DataSame format as version 1 of the object header, described above.
Header Message \#n FlagsSame format as version 1 of the object header, described above.
Header Message \#n Creation OrderThis 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 DataSame format as version 1 of the object header, described above.
GapA 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.
ChecksumThis is the checksum for the object header chunk.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_stmgroup IV.A.2.r. The Symbol Table Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Symbol Table Message
Header Message Type: 0x0011
Length: Fixed
Status: Required for “old style” groups; may not be repeated.
Description:Each “old style” group has a v1 B-tree and a local heap for storing symbol table entries, + which are located with this message.
Format of data: See the tables below.
+ + + + + + + + + + + + + + + +
Symbol Table Message
bytebytebytebyte

v1 B-tree AddressO


Local Heap AddressO

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + +
Field NameDescription
v1 B-tree AddressThis value is the address of the v1 B-tree containing the symbol table entries for the group.
Local Heap AddressThis value is the address of the local heap containing the link names for the symbol table + entries for the group.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_mod IV.A.2.s. The Object Modification Time Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Object Modification Time
Header Message Type: 0x0012
Length: Fixed
Status: Optional; may not be repeated.
Description:The object modification time is a timestamp which indicates the time of the last modification of + an object. The time is updated when any object header message changes according to the system clock + where the change was posted.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + +
Modification Time Message
bytebytebytebyte
VersionReserved (zero)
Seconds After UNIX Epoch
+ + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number is used for changes in the format of Object Modification Time and is described + here: + + + + + + + + + + + + + +
VersionDescription
0Never used.
1Used by Version 1.6.1 and after of the library to encode time. In this version, the time is + the seconds after Epoch.
Seconds After UNIX EpochA 32-bit unsigned integer value that stores the number of seconds since 0 hours, 0 minutes, + 0 seconds, January 1, 1970, Coordinated Universal Time.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_btreek IV.A.2.t. The B-tree ‘K’ Values Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: B-tree ‘K’ Values
Header Message Type: 0x0013
Length: Fixed
Status: Optional; may not be repeated.
Description:This message retrieves non-default ‘K’ values for internal and leaf nodes of a group + or indexed storage v1 B-trees. This message is only found in the superblock extension.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + +
B-tree ‘K’ Values Message
bytebytebytebyte
VersionIndexed Storage Internal Node KThis space inserted only to align table nicely
Group Internal Node KGroup Leaf Node K
+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number for this message. This document describes version 0.
Indexed Storage Internal Node KThis is the node ‘K’ value for each internal node of an indexed storage v1 B-tree. + See the description of this field in version 0 and 1 of the superblock as well the section on + v1 B-trees.
Group Internal Node KThis is the node ‘K’ value for each internal node of a group v1 B-tree. See the + description of this field in version 0 and 1 of the superblock as well as the section + on v1 B-trees.
Group Leaf Node KThis is the node ‘K’ value for each leaf node of a group v1 B-tree. See the + description of this field in version 0 and 1 of the superblock as well as the section on v1 + B-trees.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_drvinfo IV.A.2.u. The Driver Info Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Driver Info
Header Message Type: 0x0014
Length: Varies
Status: Optional; may not be repeated.
Description:This message contains information needed by the file driver to reopen a file. This message is + only found in the superblock extension: see the @ref subsec_fmt2_boot_supext section + for more information. For more information on the fields in the driver info message, see the + @ref subsec_fmt2_boot_driver section; those who use the multi and family file drivers will find + this section particularly helpful.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + +
Driver Info Message
bytebytebytebyte
VersionThis space inserted only to align table nicely

Driver Identification
Driver Information SizeThis space inserted only to align table nicely


Driver Information (variable size)


+ + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number for this message. This document describes version 0.
Driver IdentificationThis is an eight-byte ASCII string without null termination which identifies the driver.
Driver Information SizeThe size in bytes of the Driver Information field of this message.
Driver InformationDriver information is stored in a format defined by the file driver.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_attrinfo IV.A.2.v. The Attribute Info Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Attribute Info
Header Message Type: 0x0015
Length: Varies
Status: Optional; may not be repeated.
Description:This message stores information about the attributes on an object, such as the maximum creation + index for the attributes created and the location of the attribute storage when the attributes + are stored “densely”.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + +
Attribute Info Message
bytebytebytebyte
VersionFlagsMaximum Creation Index (optional)

Fractal Heap AddressO


Attribute Name v2 B-tree AddressO


Attribute Creation Order v2 B-tree AddressO (optional)

+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number for this message. This document + describes version 0.
FlagsThis is the attribute index information flag with the following definition: + + + + + + + + + + + + + + + + + +
BitDescription
0If set, creation order for attributes is tracked.
1If set, creation order for attributes is indexed.
2-7Reserved
Maximum Creation IndexThe is the maximum creation order index value for the attributes on the object.
+ This field is present if bit 0 of Flags is set.
Fractal Heap AddressThis is the address of the fractal heap to store dense attributes.
Attribute Name v2 B-tree AddressThis is the address of the version 2 B-tree to index the names of densely stored attributes.
Attribute Creation Order v2 B-tree AddressThis is the address of the version 2 B-tree to index the creation order of densely stored + attributes.
+ This field is present if bit 1 of Flags is set.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_refcount IV.A.2.w. The Object Reference Count Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Object Reference Count
Header Message Type: 0x0016
Length: Fixed
Status: Optional; may not be repeated.
Description:This message stores the number of hard links (in groups or objects) pointing to an object: in + other words, its reference count.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + +
Object Reference Count
bytebytebytebyte
VersionThis space inserted only to align table nicely
Reference count
+ + + + + + + + + + + + + + +
Field NameDescription
VersionThe version number for this message. This document describes version 0.
Reference CountThe unsigned 32-bit integer is the reference count for the object. This message is only present + in “version 2” (or later) object headers, and if not present those object header versions, + the reference count for the object is assumed to be 1.
+ +\subsubsection subsubsec_fmt2_dataobject_hdr_msg_fsinfo IV.A.2.x. The File Space Info Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: File Space Info
Header Message Type: 0x0018
Length: Fixed
Status: Optional; may not be repeated.
Description:This message stores the file space management strategy (see description below) that the library + uses in handling file space request for the file. It also contains the free-space section + threshold used by the library’s free-space managers for the file. If the strategy is 1, + this message also contains the addresses of the file’s free-space managers which track free + space for each type of file space allocation. There are six basic types of file space allocation: + superblock, B-tree, raw data, global heap, local heap, and object header. See the description of + @ref subsec_fmt2_infra_freespaceindex as well the description of allocation types in + @ref sec_fmt2_appendixb.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
File Space Info
bytebytebytebyte
VersionStrategyThresholdL
Super-block Free-space Manager AddressO
B-tree Free-space Manager AddressO
Raw Data Free-space Manager AddressO
Global Heap Free-space Manager AddressO
Local Heap Free-space Manager AddressO
Object Header Free-space Manager AddressO
+\li Items marked with an ‘O’ in the above table are of the size specified in “Size of + Offsets” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in “Size of + Lengths” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field NameDescription
VersionThis is the version number of this message. This document describes version 0.
StrategyThis is the file space management strategy for the file. There are four types of strategies: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
1With this strategy, the HDF5 Library’s free-space managers track the free space + that results from the manipulation of HDF5 objects in the HDF5 file. The free space + information is saved when the file is closed, and reloaded when the file is reopened.
+ When space is needed for file metadata or raw data, the HDF5 Library first requests space + from the library’s free-space managers. If the request is not satisfied, the library + requests space from the aggregators. If the request is still not satisfied, the library + requests space from the virtual file driver. That is, the library will use all of the + mechanisms for allocating space.
2This is the HDF5 Library’s default file space management strategy. With this strategy, + the library’s free-space managers track the free space that results from the + manipulation of HDF5 objects in the HDF5 file. The free space information is NOT saved when + the file is closed and the free space that exists upon file closing becomes unaccounted space + in the file.
+ As with strategy #1, the library will try all of the mechanisms for allocating space. When + space is needed for file metadata or raw data, the library first requests space from the + free-space managers. If the request is not satisfied, the library requests space from the + aggregators. If the request is still not satisfied, the library requests space from the virtual + file driver.
3With this strategy, the HDF5 Library does not track free space that results from the + manipulation of HDF5 objects in the HDF5 file and the free space becomes unaccounted + space in the file.
+ When space is needed for file metadata or raw data, the library first requests space + from the aggregators. If the request is not satisfied, the library requests space from + the virtual file driver.
4With this strategy, the HDF5 Library does not track free space that results from the + manipulation of HDF5 objects in the HDF5 file and the free space becomes unaccounted + space in the file.
+ When space is needed for file metadata or raw data, the library requests space from + the virtual file driver.
ThresholdThis is the free-space section threshold. The library’s free-space managers will track + only free-space sections with size greater than or equal to threshold. The default is to + track free-space sections of all sizes.
Superblock Free-space Manager AddressThis is the address of the free-space manager for #H5FD_MEM_SUPER allocation type.
B-tree Free-space Manager AddressThis is the address of the free-space manager for #H5FD_MEM_BTREE allocation type.
Raw Data Free-space Manager AddressThis is the address of the free-space manager for #H5FD_MEM_DRAW allocation type.
Global Heap Free-space Manager AddressThis is the address of the free-space manager for #H5FD_MEM_GHEAP allocation type.
Local Heap Free-space Manager AddressThis is the address of the free-space manager for #H5FD_MEM_LHEAP allocation type.
Object Header Free-space Manager AddressThis is the address of the free-space manager for #H5FD_MEM_OHDR allocation type.
+ +\subsection subsec_fmt2_dataobject_storage IV.B. Disk Format: Level 2B - Data Object Data Storage +The data for an object is stored separately from the header information in the file and may not actually +be located in the HDF5 file itself if the header indicates that the data is stored externally. The +information for each record in the object is stored according to the dimensionality of the object +(indicated in the dataspace header message). Multi-dimensional array data is stored in C order; in other +words, the “last” dimension changes fastest. + +Data whose elements are composed of atomic datatypes are stored in IEEE format, unless +they are specifically defined as being stored in a different machine format with the architecture-type +information from the datatype header message. This means that each architecture will need to +[potentially] byte-swap data values into the internal representation for that particular machine. + +Data with a variable-length datatype is stored in the global heap of the HDF5 file. Global heap +identifiers are stored in the data object storage. + +Data whose elements are composed of reference datatypes are stored in several different ways depending +on the particular reference type involved. Object pointers are just stored as the offset of the +object header being pointed to with the size of the pointer being the same number of bytes as offsets +in the file. + +Dataset region references are stored as a heap-ID which points to the following information within the +file-heap: an offset of the object pointed to, number-type information (same format as header message), +dimensionality information (same format as header message), sub-set start and end information (in other +words, a coordinate location for each), and field start and end names (in other words, a [pointer to the] +string indicating the first field included and a [pointer to the] string name for the last field). + +Data of a compound datatype is stored as a contiguous stream of the items in the structure, with each +item formatted according to its datatype. + +\section sec_fmt2_appendixa V. Appendix A: Definitions +Definitions of various terms used in this document are included in this section. + + + + + + + + + + + + + +
TermDefinition
Undefined Address\anchor FMT2UndefinedAddress The "undefined address" for a file is a file address with all bits + set: in other words, 0xffff...ff.
Unlimited Size\anchor FMT2UnlimitedDim The "unlimited size" for a size is a value with all bits set: in other words, + 0xffff...ff.
+ +\section sec_fmt2_appendixb VI. Appendix B: File Memory Allocation Types +There are six basic types of file memory allocation as follows: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Basic Allocation TypeDescription
#H5FD_MEM_SUPERFile memory allocated for Superblock.
#H5FD_MEM_BTREEFile memory allocated for B-tree.
#H5FD_MEM_DRAWFile memory allocated for raw data.
#H5FD_MEM_GHEAPFile memory allocated for Global Heap.
#H5FD_MEM_LHEAPFile memory allocated for Local Heap.
#H5FD_MEM_OHDRFile memory allocated for Object Header.
+ +There are other file memory allocation types that are mapped to the above six basic allocation types +because they are similar in nature. The mapping is listed in the following table: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Basic Allocation TypeMapping of Allocation Types to Basic Allocation Types
#H5FD_MEM_SUPERnone
#H5FD_MEM_BTREE#H5FD_MEM_SOHM_INDEX
#H5FD_MEM_DRAW#H5FD_MEM_FHEAP_HUGE_OBJ
#H5FD_MEM_GHEAPnone
#H5FD_MEM_LHEAP#H5FD_MEM_FHEAP_DBLOCK, #H5FD_MEM_FSPACE_SINFO
#H5FD_MEM_OHDR#H5FD_MEM_FHEAP_HDR, #H5FD_MEM_FHEAP_IBLOCK, #H5FD_MEM_FSPACE_HDR, #H5FD_MEM_SOHM_TABLE
+ +Allocation types that are mapped to basic allocation types are described below: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Allocation TypeDescription
#H5FD_MEM_FHEAP_HDRFile memory allocated for Fractal Heap Header.
#H5FD_MEM_FHEAP_DBLOCKFile memory allocated for Fractal Heap Direct Blocks.
#H5FD_MEM_FHEAP_IBLOCKFile memory allocated for Fractal Heap Indirect Blocks.
#H5FD_MEM_FHEAP_HUGE_OBJFile memory allocated for huge objects in the fractal heap.
#H5FD_MEM_FSPACE_HDRFile memory allocated for Free-space Manager Header.
#H5FD_MEM_FSPACE_SINFOFile memory allocated for Free-space Section List of the free-space manager.
#H5FD_MEM_SOHM_TABLEFile memory allocated for Shared Object Header Message Table.
#H5FD_MEM_SOHM_INDEXFile memory allocated for Shared Message Record List.
+ +*/ diff --git a/doxygen/dox/H5.format.3.0.dox b/doxygen/dox/H5.format.3.0.dox new file mode 100644 index 00000000000..e7ba0ef0e19 --- /dev/null +++ b/doxygen/dox/H5.format.3.0.dox @@ -0,0 +1,12591 @@ + +/** \page FMT3 HDF5 File Format Specification Version 3.0 +
    +
  1. @ref sec_fmt3_intro +
      +
    1. @ref subsec_fmt3_intro_doc
      2. +
    2. @ref subsec_fmt3_intro_20
      3. +
    3. @ref subsec_fmt3_intro_112
      4. +
    4. @ref subsec_fmt3_intro_110
      5. +
    2. +
  2. @ref sec_fmt3_meta +
      +
    1. @ref subsec_fmt3_boot_super
      2. +
    2. @ref subsec_fmt3_boot_driver
      3. +
    3. @ref subsec_fmt3_boot_supext
      4. +
    3. +
  3. @ref sec_fmt3_infra +
      +
    1. @ref subsec_fmt3_infra_btrees +
        +
      1. @ref subsubsec_fmt3_infra_btrees_v1
        2. +
      2. @ref subsubsec_fmt3_infra_btrees_v2
        3. +
      2. +
    2. @ref subsec_fmt3_infra_symboltable
      3. +
    3. @ref subsec_fmt3_infra_symboltableentry
      4. +
    4. @ref subsec_fmt3_infra_localheap
      5. +
    5. @ref subsec_fmt3_infra_globalheap
      6. +
    6. @ref subsec_fmt3_infra_globalheapvds
      7. +
    7. @ref subsec_fmt3_infra_fractalheap
      8. +
    8. @ref subsec_fmt3_infra_freespaceindex
      9. +
    9. @ref subsec_fmt3_infra_sohm
      10. +
    4. +
  4. @ref sec_fmt3_dataobject +
      +
    1. @ref subsec_fmt3_dataobject_hdr +
        +
      1. @ref subsec_fmt3_dataobject_hdr_prefix
        2. +
          +
        1. @ref subsubsec_fmt3_dataobject_hdr_prefix_one
          2. +
        2. @ref subsubsec_fmt3_dataobject_hdr_prefix_two
          3. +
        +
      2. @ref subsec_fmt3_dataobject_hdr_msg
        3. +
          +
        1. @ref subsubsec_fmt3_dataobject_hdr_msg_nil
          2. +
        2. @ref subsubsec_fmt3_dataobject_hdr_msg_simple
          3. +
        3. @ref subsubsec_fmt3_dataobject_hdr_msg_linkinfo
          4. +
        4. @ref subsubsec_fmt3_dataobject_hdr_msg_dtmessage
          5. +
        5. @ref subsubsec_fmt3_dataobject_hdr_msg_ofvmessage
          6. +
        6. @ref subsubsec_fmt3_dataobject_hdr_msg_fvmessage
          7. +
        7. @ref subsubsec_fmt3_dataobject_hdr_msg_link
          8. +
        8. @ref subsubsec_fmt3_dataobject_hdr_msg_external
          9. +
        9. @ref subsubsec_fmt3_dataobject_hdr_msg_layout
          10. +
        10. @ref subsubsec_fmt3_dataobject_hdr_msg_bogus
          11. +
        11. @ref subsubsec_fmt3_dataobject_hdr_msg_groupinfo
          12. +
        12. @ref subsubsec_fmt3_dataobject_hdr_msg_filter
          13. +
        13. @ref subsubsec_fmt3_dataobject_hdr_msg_attribute
          14. +
        14. @ref subsubsec_fmt3_dataobject_hdr_msg_comment
          15. +
        15. @ref subsubsec_fmt3_dataobject_hdr_msg_omodified
          16. +
        16. @ref subsubsec_fmt3_dataobject_hdr_msg_shared
          17. +
        17. @ref subsubsec_fmt3_dataobject_hdr_msg_continuation
          18. +
        18. @ref subsubsec_fmt3_dataobject_hdr_msg_stmgroup
          19. +
        19. @ref subsubsec_fmt3_dataobject_hdr_msg_mod
          20. +
        20. @ref subsubsec_fmt3_dataobject_hdr_msg_btreek
          21. +
        21. @ref subsubsec_fmt3_dataobject_hdr_msg_drvinfo
          22. +
        22. @ref subsubsec_fmt3_dataobject_hdr_msg_attrinfo
          23. +
        23. @ref subsubsec_fmt3_dataobject_hdr_msg_refcount
          24. +
        24. @ref subsubsec_fmt3_dataobject_hdr_msg_fsinfo
          25. +
        +
      2. +
    2. @ref subsec_fmt3_dataobject_storage
      3. +
    +
    5. +
  5. @ref sec_fmt3_appendixa +
  6. @ref sec_fmt3_appendixb +
  7. @ref sec_fmt3_appendixc +
      +
    1. @ref subsec_fmt3_appendixc_chunk +
    2. @ref subsec_fmt3_appendixc_implicit +
    3. @ref subsec_fmt3_appendixc_fixedarr +
    4. @ref subsec_fmt3_appendixc_extarr +
    5. @ref subsec_fmt3_appendixc_appv2btree +
    +
    8. +
  8. @ref sec_fmt3_appendixd +
      +
    1. @ref subsec_fmt3_appendixd_encode +
    2. @ref subsec_fmt3_appendixd_encoderv +
    3. @ref subsec_fmt3_appendixd_encodedp +
    +
    9. +
+ + + +\section sec_fmt3_intro I. Introduction + + + + + + + + + + + + + + +
Figure 1: Relationships among the HDF5 root group, other groups, and objects
\image html FF-IH_FileGroup.gif
Figure 2: HDF5 objects -- datasets, datatypes, or dataspaces
\image html FF-IH_FileObject.gif
+ +The format of an HDF5 file on disk encompasses several key ideas of the HDF4 and AIO file formats as well +as addressing some shortcomings therein. The new format is more self-describing than the HDF4 format and +is more uniformly applied to data objects in the file. + +An HDF5 file appears to the user as a directed graph. The nodes of this graph are the higher-level HDF5 +objects that are exposed by the HDF5 APIs: +\li Groups +\li Datasets +\li Committed (formerly Named) datatypes + +At the lowest level, as information is actually written to the disk, an HDF5 file is made up of the +following objects: +\li A superblock +\li B-tree nodes +\li Heap blocks +\li Object headers +\li Object data +\li Free space + +The HDF5 library uses these lower-level objects to represent the higher-level objects that are then +presented to the user or to applications through the APIs. For instance, a group is an object header that +contains a message that points to a local heap (for storing the links to objects in the group) and to a +B-tree (which indexes the links). A dataset is an object header that contains messages that describe +datatype, dataspace, layout, filters, external files, fill value, and other elements with the layout message +pointing to either a raw data chunk or to a B-tree that points to raw data chunks. + +\subsection subsec_fmt3_intro_doc I.A. This Document +This document describes the lower-level data objects; the higher-level objects and their properties are +described in the \ref UG. + +Three levels of information comprise the file format. Level 0 contains basic information for identifying +and defining information about the file. Level 1 information contains the information about the pieces of a +file shared by many objects in the file (such as a B-trees and heaps). Level 2 is the rest of the file and +contains all of the data objects with each object partitioned into header information, also known as +metadata, and data. + +The various components of the lower-level data objects are described in pairs of tables. The first table +shows the format layout, and the second table describes the fields. The titles of format layout tables +begin with “Layout”. The titles of the tables where the fields are described begin with +“Fields”. For example, the table that describes the format of the +@ref subsubsec_fmt3_infra_btrees_v2 has a title of “Layout: Version 2 B-tree Header”, and the +fields in the version 2 B-tree header are described in the table titled “Fields: Version 2 B-tree Header”. + +The sizes of various fields in the following layout tables are determined by looking at the number of +columns the field spans in the table. There are exceptions: +\li The size may be overridden by specifying a size in parentheses +\li The size of addresses is determined by the @ref FMT3SizeOfOffsetsV0 "Size of Offsets" field +in the superblock and is indicated in this document with a superscripted ‘O’ +\li The size of length fields is determined by the @ref FMT3SizeOfLengthsV0 "Size of Lengths" field +in the superblock and is indicated in this document with a superscripted ‘L’. + +Values for all fields in this document should be treated as unsigned integers, unless otherwise noted in +the description of a field. Additionally, all metadata fields are stored in little-endian byte order. + +All checksums used in the format are computed with the +Jenkins’ lookup3 algorithm. + +Whenever a bit flag or field is mentioned for an entry, bits are numbered from the lowest bit position +in the entry. + +Various format tables in this document have cells with “This space inserted only to align table nicely”. +These entries in the table are just to make the table presentation nicer and do not represent any values +or padding in the file. + +\subsection subsec_fmt3_intro_20 I.B. Changes for HDF5 2.0 +The following sections have been changed or added for the 2.0 release: +\li Under @ref subsubsec_fmt3_dataobject_hdr_msg_dtmessage, in the Description for + “Fields:Datatype Message”, version 5 was added, as well as the new Complex class (11). + +\subsection subsec_fmt3_intro_112 I.C. Changes for HDF5 1.12 +The following sections have been changed or added for the 1.12 release: +\li Under @ref subsubsec_fmt3_dataobject_hdr_msg_dtmessage, in the Description for + “Fields:Datatype Message”, version 4 was added and Reference class (7) of the + datatype was updated to describe version 4. +\li @ref sec_fmt3_appendixd was added. + +\subsection subsec_fmt3_intro_110 I.D. Changes for HDF5 1.10 +The following sections have been changed or added for the 1.10 release: +\li In the @ref subsec_fmt3_boot_super section, version 3 of the superblock was added. +\li In the @ref subsec_fmt3_boot_supext section, a link to the Data Storage message was added. +\li In the @ref subsubsec_fmt3_infra_btrees_v2 section, additional B-tree types were added. + Tables that describe the @ref FMT3V2BtType10"type 10" and @ref FMT3V2BtType11"11" record + layouts were added at the end of the section. +\li The @ref subsec_fmt3_infra_globalheapvds was added. +\li @ref subsubsec_fmt3_dataobject_hdr_msg_layout section was changed. The name was changed, + and @ref FMT3DataLayoutV4"version 4" of the data layout message was added for the virtual type. +\li The @ref subsubsec_fmt3_dataobject_hdr_msg_fsinfo header message type was added. +\li @ref sec_fmt3_appendixc was added. Five indexing types were added. + +\section sec_fmt3_meta II. Disk Format: Level 0 - File Metadata + +\subsection subsec_fmt3_boot_super II.A. Disk Format: Level 0A - Format Signature and Superblock +The superblock may begin at certain predefined offsets within the HDF5 file, allowing a block of +unspecified content for users to place additional information at the beginning (and end) of the HDF5 file +without limiting the HDF5 library’s ability to manage the objects within the file itself. This feature +was designed to accommodate wrapping an HDF5 file in another file format or adding descriptive information +to an HDF5 file without requiring the modification of the actual file’s information. The superblock +is located by searching for the HDF5 file signature at byte offset 0, byte offset 512 and at successive +locations in the file, each a multiple of two of the previous location, in other words, at these byte +offsets: 0, 512, 1024, 2048, and so on. + +The superblock is composed of the format signature, followed by a superblock version number and information +that is specific to each version of the superblock. + +Currently, there are four versions of the superblock format: +\li Version 0 is the default format. +\li Version 1 is the same as version 0 but with the “Indexed Storage Internal Node K” + field for storing non-default B-tree ‘K’ value. +\li Version 2 has some fields eliminated and compressed from superblock format versions 0 and 1. It has + added checksum support and superblock extension to store additional superblock metadata. +\li Version 3 is the same as version 2 except that the field “File Consistency Flags” + is used for file locking. This format version will enable support for the latest version. + +Version 0 and 1 of the superblock are described below: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Superblock (Versions 0 and 1)
bytebytebytebyte

Format Signature (8 bytes)

Version \# of SuperblockVersion \# of File’s Free Space StorageVersion \# of Root Group Symbol Table EntryReserved (zero)
Version \# of Shared Header Message FormatSize of OffsetsSize of LengthsReserved (zero)
Group Leaf Node KGroup Internal Node K
File Consistency Flags
Indexed Storage Internal Node K1Reserved (zero)1
Base AddressO
Address of File Free Space InfoO
End of File AddressO
Driver Information Block AddressO
Root Group Symbol Table Entry
+\li Items marked with an ‘1’ in the above table are new in version 1 of the superblock. +\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Superblock (Versions 0 and 1)
Field NameDescription
Format SignatureThis 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: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Decimal:13772687013102610
Hexadecimal:894844460d0a1a0a
ASCII C Notation:\211HDF\\r\\n\032\\n
+
+ 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 SuperblockThis 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 InformationThis 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 index is as described in @ref subsec_fmt3_infra_freespaceindex below.
+ This field is present in version 0 and 1 of the superblock.
Version Number of the Root Group Symbol Table EntryThis 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 in @ref subsec_fmt3_infra_symboltableentry below.
+ This field is present in version 0 and 1 of the superblock.
Version Number of the Shared Header Message FormatThis 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 in @ref subsubsec_fmt3_dataobject_hdr_msg_shared below.
+ This field is present in version 0 and 1 of the superblock.
\anchor FMT3SizeOfOffsetsV0 Size of OffsetsThis 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.
\anchor FMT3SizeOfLengthsV0 Size of LengthsThis 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 KEach 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 @ref subsec_fmt3_infra_btrees below.
+ This field is present in version 0 and 1 of the superblock.
Group Internal Node KEach 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 @ref subsec_fmt3_infra_btrees below.
+ This field is present in version 0 and 1 of the superblock.
File Consistency FlagsThis field is unused and should be ignored.
+ This field is present in version 0+ of the superblock.
Indexed Storage Internal Node KEach internal node of a indexed storage B-tree will have at least this many entries but not more than + twice this many. If the ndex storage B-tree has only one internal node then it might have fewer + entries.
+ This value must be greater than zero.
+ See the @ref subsec_fmt3_infra_btrees below.
+ This field is present in version 1 of the superblock.
Base AddressThis 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 IndexThe file’s free space management is not persistent for version 0 and 1 of the superblock. + Currently this field always contains the @ref FMT3UndefinedAddress "undefined address".
+ This field is present in version 0 and 1 of the superblock.
End of File AddressThis 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 accidentally 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 AddressThis 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 @ref FMT3UndefinedAddress "undefined address".
+ This field is present in version 0 and 1 of the superblock.
Root Group Symbol Table EntryThis is the @ref subsec_fmt3_infra_symboltableentry 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.
+ +Versions 2 and 3 of the superblock is described below: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Superblock (Versions 2 and 3)
bytebytebytebyte

Format Signature (8 bytes)

Version \# of SuperblockSize of OffsetsSize of LengthsFile Consistency Flags

Base AddressO


Superblock Extension AddressO


End of File AddressO


Root Group Object Header AddressO

Superblock Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Superblock (Versions 2 and 3)
Field NameDescription
Format SignatureThis field is the same as described for versions 0 and 1 of the superblock.
Version Number of the SuperblockThis field has a value of 2 and has the same meaning as for versions 0 and 1.
Size of OffsetsThis field is the same as described for @ref FMT3SizeOfOffsetsV0 "versions 0 and 1" of the superblock.
Size of LengthsThis field is the same as described for @ref FMT3SizeOfLengthsV0 "versions 0 and 1" of the superblock.
File Consistency FlagsFor 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 AddressThis field is the same as described for versions 0 and 1 of the superblock.
Superblock Extension AddressThe field is the address of the object header for the @ref subsec_fmt3_boot_supext. If there is no + extension then this entry should be the @ref FMT3UndefinedAddress "undefined address".
End of File AddressThis field is the same as described for versions 0 and 1 of the superblock.
Root Group Object Header AddressThis is the address of the @ref sec_fmt3_dataobject, which serves as the entry point into the group + graph for the file.
Superblock ChecksumThe checksum for the superblock.
+ +\subsection subsec_fmt3_boot_driver II.B. Disk Format: Level 0B - File Driver Info +The driver information block is an optional region of the file which contains information +needed by the file driver in order to reopen a file. The format is described below: + + + + + + + + + + + + + + + + + + + + + +
Layout: Driver Information Block
bytebytebytebyte
VersionReserved
Driver Information Size

Driver Identification (8 bytes)



Driver Information (variable size)


+ + + + + + + + + + + + + + + + + + + + + + + +
Fields: Driver Information Block
Field NameDescription
VersionThe version number of the Driver Information Block. This document describes version 0.
Driver Information SizeThe size in bytes of the Driver Information field.
Driver IdentificationThis 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 InformationDriver information is stored in a format defined by the file driver (see description below).
+ +The two drivers encoded in the Driver Identification field are as follows: +\li Multi driver:
The identifier for this driver is “NCSAmulti”. This driver provides + a mechanism for segregating raw data and different types of metadata into multiple files. These files + are viewed by the library as a single virtual HDF5 file with a single file address. A maximum of 6 + files will be created for the following data: superblock, B-tree, raw data, global heap, local heap, + and object header. More than one type of data can be written to the same file. +\li Family driver:
The identifier for this driver is “NCSAfami” and is encoded in this + field for library version 1.8 and after. This driver is designed for systems that do not support files + larger than 2 gigabytes by splitting the HDF5 file address space across several smaller files. It does + nothing to segregate metadata and raw data; they are mixed in the address space just as they would be + in a single contiguous file. + +The format of the Driver Information field for the above two drivers are described below: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Multi Driver Information
bytebytebytebyte
Member MappingMember MappingMember MappingMember Mapping
Member MappingMember MappingReservedReserved

Address of Member File 1


End of Address for Member File 1


Address of Member File 2


End of Address for Member File 2


... ...


Address of Member File N


End of Address for Member File N


Name of Member File 1 (variable size)


Name of Member File 2 (variable size)


... ...


Name of Member File N (variable size)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Multi Driver Information
Field NameDescription
Member MappingThese fields are integer values from 1 to 6 indicating how the data can be mapped to or + merged with another type of data. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Member MappingDescription
1The superblock data.
2The B-tree data.
3The raw data.
4The global heap data.
5The local heap data.
6The 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.
ReservedThese fields are reserved and should always be zero.
Address of Member File NThis field specifies the virtual address at which the member file starts.
+ N is the number of member files.
End of Address for Member File NThis field is the end of allocated address for the member file.
Name of Member File NThis field is the null-terminated name of 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 for the whole + HDF5 file will substitute the %s in the string.
+
+ + + + + + + + + + + +
Layout: Family Driver Information
bytebytebytebyte

Size of Member File

+
+ + + + + + + + + + +
Fields: Family Driver Information
Field NameDescription
Size of Member FileThis field is the size of the member file in the family of files.
+ +\subsection subsec_fmt3_boot_supext II.C. Disk Format: Level 0C - Superblock Extension +The superblock extension is used to store superblock metadata which is either optional, or added +after the version of the superblock was defined. Superblock extensions may only exist when version 2+ or +later of the superblock is used. A superblock extension is an object header which may hold the following messages: +\li \ref subsec_fmt3_infra_sohm containing information to locate the master table of shared object + header message indices. +\li \ref subsubsec_fmt3_dataobject_hdr_msg_btreek containing non-default B-tree ‘K’ values. +\li \ref subsubsec_fmt3_dataobject_hdr_msg_drvinfo containing information needed by the file driver in + order to reopen a file. See also the \ref subsec_fmt3_boot_driver section above. +\li \ref subsubsec_fmt3_dataobject_hdr_msg_fsinfo containing information about file space handling in the file. + +\section sec_fmt3_infra III. Disk Format: Level 1 - File Infrastructure + +\subsection subsec_fmt3_infra_btrees III.A. Disk Format: Level 1A - B-trees and B-tree Nodes +B-trees allow flexible storage for objects which tend to grow in ways that cause the object to be stored +discontiguously. B-trees are described in various algorithms books including "Introduction to Algorithms" by +Thomas H. Cormen, Charles E. Leiserson, and Ronald L. Rivest. The B-trees are used in several places in +the HDF5 file format, when an index is needed for another data structure. + +The version 1 B-tree structure described below is the original index structure. The version 1 B-trees are +being phased out in favor of the version 2 B-trees described below. Note that both types of structures may +be found in the same file depending on the application settings when creating the file. + +\subsubsection subsubsec_fmt3_infra_btrees_v1 III.A.1. Disk Format: Level 1A1 - Version 1 B-trees +Version 1 B-trees in HDF5 files an implementation of the B-tree. The sibling nodes at a +particular level in the tree are stored in a doubly-linked list. See the “Efficient Locking +for Concurrent Operations on B-trees” paper by Phillip Lehman and S. Bing Yao as published in the + ACM Transactions on Database Systems, Vol. 6, No. 4, December 1981. + +The B-trees implemented by the file format contain one more key than the number of children. In other +words, each child pointer out of a B-tree node has a left key and a right key. The pointers out of internal +nodes point to sub-trees while the pointers out of leaf nodes point to symbol nodes and raw data chunks. +Aside from that difference, internal nodes and leaf nodes are identical. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: B-tree Nodes
bytebytebytebyte
Signature
Node TypeNode LevelEntries Used

Address of Left SiblingO


Address of Right SiblingO

Key 1 (variable size)

Address of Child 1O

Key 2 (variable size)

Address of Child 2O

...
Key 2K (variable size)

Address of Child 2KO

Key 2K+1 (variable size)
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: B-tree Nodes
Field NameDescription
SignatureThe 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 TypeEach 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 TypeDescription
0This tree points to group nodes.
1This tree points to a raw data chunk.
+
Node LevelThe 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 UsedThis 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 SiblingThis 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 @ref FMT3UndefinedAddress "undefined address".
Address of Right SiblingThis 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 @ref FMT3UndefinedAddress "undefined address".
Keys and Child PointersEach 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.
KeyThe 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 @ref FMT3SizeOfLengthsV0 "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-4Size of chunk in bytes.
Bytes 4-8Filter 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 fieldsThe 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 indices, each with the value of + 5, followed by a 0 value.
+
Child PointerThe 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 @ref subsec_fmt3_infra_symboltableentry, which contains + information for multiple symbol table entries.
+ +Conceptually, each B-tree node looks like this: + + + + + + + + + + + + + + + + + + + + + + +
key[0] child[0] key[1] child[1] key[2]; ... ... key[N-1] child[N-1] key[N]
+where child[i] is a pointer to a sub-tree (at a level above Level 0) or to data (at Level 0). +Each key[i] describes an item stored by the B-tree (a chunk or an object of a group node). +The range of values represented by child[i] is indicated by key[i] and key[i+1]. + +The following question must next be answered: "Is the value described by key[i] contained in +child[i-1] or in child[i]?" The answer depends on the type of tree. In trees for groups (node +type 0) the object described by key[i] is the greatest object contained in child[i-1] while +in chunk trees (node type 1) the chunk described by key[i] is the least chunk in child[i]. + +That means that key[0] for group trees is sometimes unused; it points to offset zero in the heap, which is +always the empty string and compares as "less-than" any valid object name. + +And key[N] for chunk trees is sometimes unused; it contains a chunk offset which compares as +"greater-than" any other chunk offset and has a chunk byte size of zero to indicate that it is not actually +allocated. + +\subsubsection subsubsec_fmt3_infra_btrees_v2 III.A.2. Disk Format: Level 1A2 - Version 2 B-trees +Version 2 (v2) B-trees are “traditional” B-trees, with one major difference. Instead of just using +a simple pointer (or address in the file) to a child of an internal node, the pointer to the child node +contains two additional pieces of information: the number of records in the child node itself, and the +total number of records in the child node and all its descendants. Storing this additional information +allows fast array-like indexing to locate the nth record in the B-tree. + +The entry into a version 2 B-tree is a header which contains global information about the structure of +the B-tree. The root node address field in the header points to the B-tree root node, which is +either an internal or leaf node, depending on the value in the header’s depth field. An +internal node consists of records plus pointers to further leaf or internal nodes in the tree. A leaf +node consists of solely of records. The format of the records depends on the B-tree type (stored in +the header). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Version 2 B-tree Header
bytebytebytebyte
Signature
VersionTypeThis space inserted only to align table nicely
Node Size
Record SizeDepth
Split PercentMerge PercentThis space inserted only to align table nicely

Root Node AddressO

Number of Records in Root NodeThis space inserted only to align table nicely

Total Number of Records in B-treeL

Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 2 B-tree Header
Field NameDescription
SignatureThe ASCII character string “BTHD” is used to indicate the header of a + version 2 (v2) B-tree node.
VersionThe version number for this B-tree header. This document describes version 0.
TypeThis field indicates the type of B-tree: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0This B-tree is used for testing only. This value should not be used for storing + records in actual HDF5 files.
1This B-tree is used for indexing indirectly accessed, non-filtered ‘huge’ + fractal heap objects.
2This B-tree is used for indexing indirectly accessed, filtered ‘huge’ + fractal heap objects.
3This B-tree is used for indexing directly accessed, non-filtered ‘huge’ + fractal heap objects.
4This B-tree is used for indexing directly accessed, filtered ‘huge’ + fractal heap objects.
5This B-tree is used for indexing the ‘name’ field for links in indexed + groups.
6This B-tree is used for indexing the ‘creation order’ field for links + in indexed groups.
7This B-tree is used for indexing shared object header messages.
8This B-tree is used for indexing the ‘name’ field for indexed + attributes.
9This B-tree is used for indexing the ‘creation order’ field for + indexed attributes.
10This B-tree is used for indexing chunks of datasets with no filters and with more + than one dimension of unlimited extent.
11This 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 SizeThis is the size in bytes of all B-tree nodes.
Record SizeThis field is the size in bytes of the B-tree record.
DepthThis is the depth of the B-tree.
Split PercentThe percent full that a node needs to increase above before it is split.
Merge PercentThe percent full that a node needs to be decrease below before it is split.
Root Node AddressThis is the address of the root B-tree node. A B-tree with no records will have the + @ref FMT3UndefinedAddress "undefined address" in this field.
Number of Records in Root NodeThis is the number of records in the root node.
Total Number of Records in B-treeThis is the total number of records in the entire B-tree.
ChecksumThis is the checksum for the B-tree header.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Version 2 B-tree Internal Node
bytebytebytebyte
Signature
VersionTypeRecords 0, 1, 2...N-1 (variable size)

Child Node Pointer 0O


Number of Records N0 for Child Node 0 (variable size)

Total Number of Records for Child Node 0 (optional, variable size)

Child Node Pointer 1O


Number of Records N1 for Child Node 1 (variable size)

Total Number of Records for Child Node 1 (optional, variable size)
...

Child Node Pointer NO


Number of Records Nn for Child Node N (variable size)

Total Number of Records for Child Node N (optional, variable size)
Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 2 B-tree Internal Node
Field NameDescription
SignatureThe ASCII character string “ BTIN ” is used to indicate the internal node + of a B-tree.
VersionThe version number for this B-tree internal node. This document describes version 0.
TypeThis field is the type of the B-tree node. It should always be the same as the B-tree type in + the header.
RecordsThe 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 PointerThis field is the address of the child node pointed to by the internal node.
Number of Records in Child NodeThis 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 NodeThis 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.
ChecksumThis is the checksum for this node.
+ + + + + + + + + + + + + + + + + + + + +
Layout: Version 2 B-tree Leaf Node
bytebytebytebyte
Signature
VersionTypeRecord 0, 1, 2...N-1 (variable size)
Checksum
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 2 B-tree Leaf Node
Field NameDescription
SignatureThe ASCII character string “ BTLF “ is used to indicate the leaf node + of a version 2 (v2) B-tree.
VersionThe version number for this B-tree leaf node. This document describes version 0.
TypeThis field is the type of the B-tree node. It should always be the same as the B-tree type in + the header.
RecordsThe 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.
ChecksumThis is the checksum for this node.
+ +The record layout for each stored (in other words, non-testing) B-tree type is as follows: + + + + + + + + + + + + + + + + + +
Layout: Version 2 B-tree, Type 1 Record Layout - Indirectly Accessed, Non-Filtered, + ‘Huge’ Fractal Heap Objects
bytebytebytebyte

Huge Object AddressO


Huge Object LengthL


Huge Object IDL

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + +
Fields: Version 2 B-tree, Type 1 Record Layout - Indirectly Accessed, Non-Filtered, + ‘Huge’ Fractal Heap Objects
Field NameDescription
Huge Object AddressThe address of the huge object in the file.
Huge Object LengthThe length of the huge object in the file.
Huge Object IDThe heap ID for the huge object.
+ + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Version 2 B-tree, Type 2 Record Layout - Indirectly Accessed, Filtered, ‘Huge’ + Fractal Heap Objects
bytebytebytebyte

Filtered Huge Object AddressO


Filtered Huge Object LengthL

Filter Mask

Filtered Huge Object Memory SizeL


Huge Object IDL

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 2 B-tree, Type 2 Record Layout - Indirectly Accessed, Filtered, ‘Huge’ + Fractal Heap Objects
Field NameDescription
Filtered Huge Object AddressThe address of the filtered huge object in the file.
Filtered Huge Object LengthThe length of the filtered huge object in the file.
Filter MaskA 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 SizeThe size of the de-filtered huge object in memory.
Huge Object IDThe heap ID for the huge object.
+ + + + + + + + + + + + + + + +
Layout: Version 2 B-tree, Type 3 Record Layout - Directly Accessed, Non-Filtered, ‘Huge’ + Fractal Heap Objects
bytebytebytebyte

Huge Object AddressO


Huge Object LengthL

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + +
Fields: Version 2 B-tree, Type 3 Record Layout - Directly Accessed, Non-Filtered, ‘Huge’ + Fractal Heap Objects
Field NameDescription
Huge Object AddressThe address of the huge object in the file.
Huge Object LengthThe length of the huge object in the file.
+ + + + + + + + + + + + + + + + + + + + + +
Layout: Version 2 B-tree, Type 4 Record Layout - Directly Accessed, Filtered, ‘Huge’ + Fractal Heap Objects
bytebytebytebyte

Filtered Huge Object AddressO


Filtered Huge Object LengthL

Filter Mask

Filtered Huge Object Memory SizeL

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 2 B-tree, Type 4 Record Layout - Directly Accessed, Filtered, ‘Huge’ + Fractal Heap Objects
Field NameDescription
Filtered Huge Object AddressThe address of the filtered huge object in the file.
Filtered Huge Object LengthThe length of the filtered huge object in the file.
Filter MaskA 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 SizeThe size of the de-filtered huge object in memory.
+ + + + + + + + + + + + + + + + + + +
Layout: Version 2 B-tree, Type 5 Record Layout - Link Name for Indexed Group
bytebytebytebyte
Hash of Name
ID (bytes 1-4)
ID (bytes 5-7)
+ + + + + + + + + + + + + + + +
Fields: Version 2 B-tree, Type 5 Record Layout - Link Name for Indexed Group
Field NameDescription
HashThis 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.
IDThis is a 7-byte sequence of bytes and is the heap ID for the link record in the group’s + fractal heap.
+ + + + + + + + + + + + + + + + + + + +
Layout: Version 2 B-tree, Type 6 Record Layout - Creation Order for Indexed Group
bytebytebytebyte

Creation Order (8 bytes)

ID (bytes 1-4)
ID (bytes 5-7)
+ + + + + + + + + + + + + + + +
Fields: Version 2 B-tree, Type 6 Record Layout - Creation Order for Indexed Group
Field NameDescription
Creation OrderThis field is the creation order value for the link.
IDThis is a 7-byte sequence of bytes and is the heap ID for the link record in the group’s + fractal heap.
+ + + + + + + + + + + + + + + + + + + + + + +
Layout: Version 2 B-tree, Type 7 Record Layout - Shared Object Header Messages + (Sub-Type 0 - Message in Heap)
bytebytebytebyte
Message LocationThis space inserted only to align table nicely
Hash
Reference Count

Heap ID (8 bytes)

+ + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 2 B-tree, Type 7 Record Layout - Shared Object Header Messages + (Sub-Type 0 - Message in Heap)
Field NameDescription
Message LocationThis field Indicates the location where the message is stored: + + + + + + + + + + + + + +
ValueDescription
0Shared message is stored in shared message index heap.
1Shared message is stored in object header.
+
HashThis field is hash value of the shared message. The hash value is the Jenkins’ lookup3 + checksum algorithm applied to the shared message.
Reference CountThe number of objects which reference this message.
Heap IDThis is an 8-byte sequence of bytes and is the heap ID for the shared message in the shared + message index’s fractal heap.
+ + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Version 2 B-tree, Type 7 Record Layout - Shared Object Header Messages + (Sub-Type 1 - Message in Object Header)
bytebytebytebyte
Message LocationThis space inserted only to align table nicely
Hash
Reserved (zero)Message TypeObject Header Index

Object Header AddressO

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 2 B-tree, Type 7 Record Layout - Shared Object Header Messages + (Sub-Type 1 - Message in Object Header)
Field NameDescription
Message LocationThis field Indicates the location where the message is stored: + + + + + + + + + + + + + +
ValueDescription
0Shared message is stored in shared message index heap.
1Shared message is stored in object header.
+
HashThis field is hash value of the shared message. The hash value is the Jenkins’ lookup3 + checksum algorithm applied to the shared message.
Message TypeThe object header message type of the shared message.
Object Header IndexThis field indicates that the shared message is the nth message of its type in the + specified object header.
Object Header AddressThe address of the object header containing the shared message.
+ + + + + + + + + + + + + + + + + + + + + + +
Layout: Version 2 B-tree, Type 8 Record Layout - Attribute Name for Indexed Attributes
bytebytebytebyte

Heap ID (8 bytes)

Message FlagsThis space inserted only to align table nicely
Creation Order
Hash of Name
+ + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 2 B-tree, Type 8 Record Layout - Attribute Name for Indexed Attributes
Field NameDescription
Heap IDThis is an 8-byte sequence of bytes and is the heap ID for the attribute in the object’s + attribute fractal heap.
Message FlagsThe object header message flags for the attribute message.
Creation OrderThis field is the creation order value for the attribute.
HashThis 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.
+ + + + + + + + + + + + + + + + + + + +
Layout: Version 2 B-tree, Type 9 Record Layout- Creation Order for Indexed Attributes
bytebytebytebyte

Heap ID (8 bytes)

Message FlagsThis space inserted only to align table nicely
Creation Order
+ + + + + + + + + + + + + + + + + + + + +
Fields: Version 2 B-tree, Type 9 Record Layout- Creation Order for Indexed Attributes
Field NameDescription
Heap IDThis is an 8-byte sequence of bytes and is the heap ID for the attribute in the object’s + attribute fractal heap.
Message FlagsThe object header message flags for the attribute message.
Creation OrderThis field is the creation order value for the attribute.
+ + + + + + + + + + + + + + + + + + + + + + + + +
\anchor FMT3V2BtType10 Layout: Version 2 B-tree, Type 10 Record Layout - Non-filtered Dataset Chunks
bytebytebytebyte

AddressO


Dimension 0 Scaled Offset (8 bytes)


Dimension 1 Scaled Offset (8 bytes)


...


Dimension \#n Scaled Offset (8 bytes)

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + +
Fields: Version 2 B-tree, Type 11 Record Layout - Filtered Dataset Chunks
Field NameDescription
AddressThis field is the address of the dataset chunk in the file.
Dimension \#n Scaled OffsetThis field is the scaled offset of the chunk within the dataset. n is the number of + dimensions for the dataset. The first scaled offset stored in the list is for the slowest + changing dimension, and the last scaled offset stored is for the fastest changing dimension. + Scaled offset is calculated by dividing the chunk dimension sizes into the chunk offsets.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
\anchor FMT3V2BtType11 Layout: Version 2 B-tree, Type 11 Record Layout - Filtered Dataset Chunks
bytebytebytebyte

AddressO


Chunk Size (variable size; at most 8 bytes)

Filter Mask

Dimension 0 Scaled Offset (8 bytes)


Dimension 1 Scaled Offset (8 bytes)


...


Dimension \#n Scaled Offset (8 bytes)

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 2 B-tree, Type 5 Record Layout - Non-filtered Dataset Chunks
Field NameDescription
AddressThis field is the address of the dataset chunk in the file.
Chunk SizeThis field is the size of the dataset chunk in bytes.
Filter MaskThis field is the filter mask which indicates the filter + to skip for the dataset chunk. Each filter has an index + number in the pipeline and if that filter is skipped, + the bit corresponding to its index is set.
Dimension \#n Scaled OffsetThis field is the scaled offset of the chunk within the dataset. n is the number of + dimensions for the dataset. The first scaled offset stored in the list is for the slowest + changing dimension, and the last scaled offset stored is for the fastest changing dimension.
+ +\subsection subsec_fmt3_infra_symboltable III.B. Disk Format: Level 1B - Group Symbol Table Nodes +A group is an object internal to the file that allows arbitrary nesting of objects within the file (including +other groups). A group maps a set of link names in the group to a set of relative file addresses of objects +in the file. Certain metadata for an object to which the group points can be cached in +object’s header. + +An HDF5 object name space can be stored hierarchically by partitioning the name into components and storing +each component as a link in a group. The link for a non-ultimate component points to the group containing the +next component. The link for the last component points to the object being named. + +One implementation a group is a collection of symbol table nodes indexed by a B-tree. Each symbol table +node contains entries for one or more links. If an attempt is made to add a link to an already full +symbol table node containing 2K entries, then the node is split and one node contains K +symbols and the other contains K+1 symbols. + + + + + + + + + + + + + + + + + + + + +
Layout: Symbol Table Node (A Leaf of a B-tree)
bytebytebytebyte
Signature
Version NumberReserved (zero)Number of Symbols


Group Entries


+ + + + + + + + + + + + + + + + + + + + + + + +
Fields: Symbol Table Node (A Leaf of a B-tree)
Field NameDescription
SignatureThe 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 NumberThe version number for the symbol table node. This document describes version 1. (There is no version + ‘0’ of the symbol table node)
Number of SymbolsAlthough 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.
Group EntriesEach 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 @ref subsec_fmt3_boot_super.
+ +\subsection subsec_fmt3_infra_symboltableentry III.C. Disk Format: Level 1C - Symbol Table Entry +Each symbol table entry in a symbol table node is designed to allow for very fast browsing of stored objects. +Toward that design goal, the symbol table entries include space for caching certain constant metadata from the +object header. + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Symbol Table Entry
bytebytebytebyte
Link Name OffsetO
Object Header AddressO
Cache Type
Reserved (zero)


Scratch-pad Space (16 bytes)


+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Symbol Table Entry
Field NameDescription
Link Name OffsetThis is the byte offset into the group’s local heap for the name of the link. The name is null + terminated.
Object Header AddressEvery 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 TypeThe cache type is determined from the object header. It also determines the format for the scratch-pad + space.
+ + + + + + + + + + + + + + + + + +
Type:Description:
0No 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.
1Group object header metadata is cached in the scratch-pad space. This implies that the symbol table + entry refers to another group.
2The 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.
+
ReservedThese 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 SpaceThis space is used for different purposes, depending on the value of the Cache Type field. Any meta-data + 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.
+ +\subsubsection subsubsec_fmt3_infra_symboltableentry_scratch Format of the Scratch-pad Space +The symbol table entry scratch-pad space is formatted according to the value in the Cache Type field. + +If the Cache Type field contains the value zero ((0)) then no information is stored in the +scratch-pad space. + +If the Cache Type field contains the value one (1), then the scratch-pad space contains +cached metadata for another object header in the following format: + + + + + + + + + + + + + +
Layout: Object Header Scratch-pad Format
bytebytebytebyte
Address of B-treeO
Address of Name HeapO
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + +
Fields: Object Header Scratch-pad Format
Field NameDescription
Address of B-treeThis is the file address for the root of the group’s B-tree.
Address of Name HeapThis is the file address for the group’s local heap, in which are stored the group’s + symbol names.
+ +If the Cache Type field contains the value two ((2)), then the scratch-pad space contains +cached metadata for a symbolic link in the following format: + + + + + + + + + + + +
Layout: Symbolic Link Scratch-pad Format
bytebytebytebyte
Offset to Link Value
+ + + + + + + + + + + +
Fields: Symbolic Link Scratch-pad Format
Field NameDescription
Offset to Link ValueThe 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.
+ +\subsection subsec_fmt3_infra_localheap III.D. Disk Format: Level 1D - Local Heaps +A local heap is a collection of small pieces of data that are particular to a single object in the HDF5 file. +Objects can be inserted and removed from the heap at any time. The address of a heap does not change once +the heap is created. For example, a group stores addresses of objects in symbol table nodes with the names +of links stored in the group’s local heap. + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Local Heap
bytebytebytebyte
Signature
VersionReserved (zero)
Data Segment SizeL
Offset to Head of Free-listL
Address of Data SegmentO
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Local Heap
Field NameDescription
SignatureThe 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.
VersionEach 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 SizeThe 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-listThis is the offset within the heap data segment of the first free block (or the + @ref FMT3UndefinedAddress "undefined address" if there is no no free block). The free block + contains “@ref FMT3SizeOfLengthsV0 "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 “@ref FMT3SizeOfLengthsV0 "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 * “@ref FMT3SizeOfLengthsV0 "Size of Lengths"”.
Address of Data SegmentThe 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.
+ +Objects within a local heap should be aligned on an 8-byte boundary. + +\subsection subsec_fmt3_infra_globalheap III.E. Disk Format: Level 1E - Global Heap +Each HDF5 file has a global heap which stores various types of information which is typically shared between +datasets. The global heap was designed to satisfy these goals: +
    +
  1. Repeated access to a heap object must be efficient without resulting in repeated file I/O requests. + Since global heap objects will typically be shared among several datasets, it is probable that the + object will be accessed repeatedly.
    2. +
  2. Collections of related global heap objects should result in fewer and larger I/O requests. For + instance, a dataset of object references will have a global heap object for each reference. Reading + the entire set of object references should result in a few large I/O requests instead of one small + I/O request for each reference.
    3. +
  3. It should be possible to remove objects from the global heap and the resulting file hole should be + eligible to be reclaimed for other uses.
    4. +
+ +The implementation of the heap makes use of the memory management already available at the file level and +combines that with a new object called a collection to achieve goal B. The global heap is +the set of all collections. Each global heap object belongs to exactly one collection and each collection +contains one or more global heap objects. For the purposes of disk I/O and caching, a collection is treated +as an atomic object, addressing goal A. + +When a global heap object is deleted from a collection (which occurs when its reference count falls to zero), +objects located after the deleted object in the collection are packed down toward the beginning of the +collection and the collection’s global heap object 0 is created (if possible) or its size is increased +to account for the recently freed space. There are no gaps between objects in each collection, with the possible +exception of the final space in the collection, if it is not large enough to hold the header for the +collection’s global heap object 0. These features address goal C. + +The HDF5 library creates global heap collections as needed, so there may be multiple collections throughout +the file. The set of all of them is abstractly called the “global heap”, although they do not +actually link to each other, and there is no global place in the file where you can discover all of the +collections. The collections are found simply by finding a reference to one through another object in the file. +For example, data of variable-length datatype elements is stored in the global heap and is accessed via a +global heap ID. The format for global heap IDs is described at the end of this section. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: A Global Heap Collection
bytebytebytebyte
Signature
VersionReserved (zero)

Collection SizeL


Global Heap Object 1


Global Heap Object 2


...


Global Heap Object N


Global Heap Object 0 (free space)

+\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: A Global Heap Collection
Field NameDescription
SignatureThe 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.
VersionEach 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 SizeThis 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 NThe objects are stored in any order with no intervening unused space.
Global Heap Object 0Global 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.
+ + + + + + + + + + + + + + + + + + + + + + +
Layout: Global Heap Object
bytebytebytebyte
Heap Object IndexReference Count
Reserved (zero)

Object SizeL


Object Data

+\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Global Heap Object
Field NameDescription
Heap Object IndexEach 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 CountAll 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.
ReservedZero 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 DataThe object data is treated as a one-dimensional array of bytes to be interpreted by the caller.
+ +
+\anchor FMT3GlobalHeapID

The format for the ID used to locate an object in the global heap is described here:

+ + + + + + + + + + + + + + +
Layout: Global Heap ID
bytebytebytebyte

Collection AddressO

Object Index
+\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + +
Fields: Global Heap ID
Field NameDescription
Collection AddressThis field is the address of the global heap collection where the data object is stored.
IDThis field is the index of the data object within the global heap collection.
+ +\subsection subsec_fmt3_infra_globalheapvds III.F. Disk Format: Level 1F - Global Heap Block for Virtual Datasets +The layout for the global heap block used with virtual datasets is described below. For more information +on global heaps, see “ @ref subsec_fmt3_infra_globalheap ” + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Global Heap Block for Virtual Dataset
bytebytebytebyte
VersionThis space inserted only to align table nicely

Num EntriesL


Source Filename \#1 (variable size)


Source Dataset \#1 (variable size)


Source Selection \#1 (variable size)


Virtual Selection \#1 (variable size)

.
.
.

Source Filename \#n (variable size)


Source Dataset \#n (variable size)


Source Selection \#n (variable size)


Virtual Selection \#n (variable size)

Checksum
+\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Global Heap Block for Virtual Dataset
Field NameDescription
VersionThe version number for the block; the value is 0.

Num EntriesL

The number of entries in the block.

Source Filename \#n (variable size)

The source file name where the source dataset is located.

Source Dataset \#n (variable size)

The source dataset name that is mapped to the virtual dataset.

Source Selection \#n (variable size)

The @ref FMT3DataspaceSEL "dataspace selection" in the source dataset that is mapped + to the virtual selection.

Virtual Selection \#n (variable size)

This is the @ref FMT3DataspaceSEL "dataspace selection" in the virtual dataset that + is mapped to the source selection.
ChecksumThis is the checksum for the block.
+ +\subsection subsec_fmt3_infra_fractalheap III.G. Disk Format: Level 1G - Fractal Heap +Each fractal heap consists of a header and zero or more direct and indirect blocks (described below). +The header contains general information as well as initialization parameters for the doubling +table. The Address of Root Block field in the header points to the first direct or indirect block in +the heap. + +Fractal heaps are based on a data structure called a doubling table. A doubling table provides +a mechanism for quickly extending an array-like data structure that minimizes the number of empty blocks +in the heap, while retaining very fast lookup of any element within the array. More information on +fractal heaps and doubling tables can be found in the RFC +“\ref_rfc20070115 .” + +The fractal heap implements the doubling table structure with indirect and direct blocks. Indirect +blocks in the heap do not actually contain data for objects in the heap, their “size” is +abstract - they represent the indexing structure for locating the direct blocks in the doubling table. +Direct blocks contain the actual data for objects stored in the heap. + +All indirect blocks have a constant number of block entries in each row, called the width +of the doubling table (see Table Width field in the header). The number of rows for each indirect +block in the heap is determined by the size of the block that the indirect block represents in the doubling table +(calculation of this is shown below) and is constant, except for the “root” indirect block, +which expands and shrinks its number of rows as needed. + +Blocks in the first two rows of an indirect block are Starting Block Size number of +bytes in size. For example, if the row width of the doubling table is 4, then the first eight block +entries in the indirect block are Starting Block Size number of bytes in size. The blocks in each +subsequent row are twice the size of the blocks in the previous +row. In other words, blocks in the third row are twice the Starting Block Size, blocks in the +fourth row are four times the Starting Block Size, and so on. Entries for blocks up to the +Maximum Direct Block Size point to direct blocks, and entries for blocks greater than that size +point to further indirect blocks (which have their own entries for direct and indirect blocks). Starting +Block Size and Maximum Direct Block Size are fields stored in the header. + +The number of rows of blocks, nrows, in an indirect block is calculated +by the following expression:

+nrows = (log2(iblock_size) - log2(<Starting Block Size>)) + 1 +where block_size is the size of the block that the indirect block +represents in the doubling table. For example, to represent a block with block_size equals to 1024, +and Starting Block Size equals to 256, three rows are needed. + +The maximum number of rows of direct blocks, max_dblock_rows, in any indirect block of a fractal +heap is given by the following expression:

+max_dblock_rows = (log2(<Maximum Direct Block Size>) - +log2(<Starting Block Size>)) + 2 + +Using the computed values for nrows and max_dblock_rows, along with the Width +of the doubling table, the number of direct and indirect block entries (K and N in the +indirect block description, below) in an indirect block can be computed:

+K = MIN(nrows, max_dblock_rows) * Table Width

+If nrows is less than or equal to max_dblock_rows, N is 0. Otherwise, N +is simply computed:

+N = K - (max_dblock_rows * Table Width) + +The size of indirect blocks on disk is determined by the number of rows in the indirect block +(computed above). The size of direct blocks on disk is exactly the size of the block in the doubling table. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Fractal Heap Header
bytebytebytebyte
Signature
VersionThis space inserted only to align table nicely
Heap ID LengthI/O Filters’ Encoded Length
FlagsThis space inserted only to align table nicely
Maximum Size of Managed Objects

Next Huge Object IDL


v2 B-tree Address of Huge ObjectsO


Amount of Free Space in Managed BlocksL


Address of Managed Block Free Space ManagerO


Amount of Managed Space in HeapL


Amount of Allocated Managed Space in HeapL


Offset of Direct Block Allocation Iterator in Managed SpaceL


Number of Managed Objects in HeapL


Size of Huge Objects in HeapL


Number of Huge Objects in HeapL


Size of Tiny Objects in HeapL


Number of Tiny Objects in HeapL

Table WidthThis space insertedonly to align table nicely

Starting Block SizeL


Maximum Direct Block SizeL

Maximum Heap SizeStarting \# of Rows in Root Indirect Block

Address of Root BlockO

Current \# of Rows in Root Indirect BlockThis space inserted only to align table nicely

Size of Filtered Root Direct Block (optional)L

I/O Filter Mask (optional)
I/O Filter Information (optional, variable size)
Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Fractal Heap Header
Field NameDescription
SignatureThe 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.
VersionThis document describes version 0.
Heap ID LengthThis is the length in bytes of heap object IDs for this heap.
I/O Filters’ Encoded LengthThis is the size in bytes of the encoded I/O Filter Information.
FlagsThis field is the heap status flag and is a bit field indicating additional information about + the fractal heap. + + + + + + + + + + + + + + + + + +
Bit(s)Description
0If 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. +
1If set, the direct blocks in the heap are checksummed.
2-7Reserved
Maximum Size of Managed ObjectsThis 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 IDThis is the next ID value to use for a huge object in the heap.
v2 B-tree Address of Huge ObjectsThis is the address of the @ref subsubsec_fmt3_infra_btrees_v2 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 BlocksThis is the total amount of free space in managed direct blocks (in bytes).
Address of Managed Block Free Space ManagerThis is the address of the @ref subsec_fmt3_infra_freespaceindex + for managed blocks.
Amount of Managed Space in HeapThis 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 HeapThis 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 SpaceThis 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 HeapThis is the number of managed objects in the heap.
Size of Huge Objects in HeapThis is the total size of huge objects in the heap (in bytes).
Number of Huge Objects in HeapThis is the number of huge objects in the heap.
Size of Tiny Objects in HeapThis is the total size of tiny objects that are packed in heap IDs (in bytes).
Number of Tiny Objects in HeapThis is the number of tiny objects that are packed in heap IDs.
Table WidthThis is the number of columns in the doubling table for managed blocks. This value + must be a power of two.
Starting Block SizeThis 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 SizeThis 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 SizeThis 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 BlockThis 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 BlockThis is the address of the root block for the heap. It can be the + @ref FMT3UndefinedAddress "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 BlockThis 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 BlockThis 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 MaskThis 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 + @ref subsubsec_fmt3_infra_btrees_v1. This field is only stored in the header if the I/O Filters’ + Encoded Length is greater than 0.
I/O Filter InformationThis 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 @ref subsubsec_fmt3_dataobject_hdr_msg_filter message. The size + of this field is determined by I/O Filters’ Encoded Length.
ChecksumThis is the checksum for the header.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Fractal Heap Direct Block
bytebytebytebyte
Signature
VersionThis space inserted only to align table nicely

Heap Header AddressO

Block Offset (variable size)
Checksum (optional)

Object Data (variable size)

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Fractal Heap Direct Block
Field NameDescription
SignatureThe 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.
VersionThis document describes version 0.
Heap Header AddressThis is the address for the fractal heap header that this block belongs to. This field is + principally used for file integrity checking.
Block OffsetThis 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.
ChecksumThis 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 DataThis 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).
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Fractal Heap Indirect Block
bytebytebytebyte
Signature
VersionThis space inserted only to align table nicely

Heap Header AddressO

Block Offset (variable size)

Child Direct Block \#0 AddressO


Size of Filtered Direct Block \#0 (optional) L

Filter Mask for Direct Block \#0 (optional)

Child Direct Block \#1 AddressO


Size of Filtered Direct Block \#1 (optional)L

Filter Mask for Direct Block \#1 (optional)
...

Child Direct Block \#K-1 AddressO


Size of Filtered Direct Block \#K-1 (optional)L

Filter Mask for Direct Block \#K-1 (optional)

Child Indirect Block \#0 AddressO


Child Indirect Block \#1 AddressO

...

Child Indirect Block \#N-1 AddressO

Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Fractal Heap Indirect Block
Field NameDescription
SignatureThe 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.
VersionThis document describes version 0.
Heap Header AddressThis is the address for the fractal heap header that this block belongs to. This field is principally + used for file integrity checking.
Block OffsetThis 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 AddressThis 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 \#KThis 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 \#KThis 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 @ref subsubsec_fmt3_infra_btrees_v1. If + no I/O filters are present for this heap, this field is not present.
Child Indirect Block \#N AddressThis 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.
ChecksumThis is the checksum for the indirect block.
+ +An object in the fractal heap is identified by means of a fractal heap ID, which encodes information to +locate the object in the heap. Currently, the fractal heap stores an object in one of three ways, +depending on the object’s size: + + + + + + + + + + + + + + + + + +
TypeDescription
TinyWhen an object is small enough to be encoded in the heap ID, the object’s data is embedded + in the fractal heap ID itself. There are two sub-types for this type of object: normal and extended. + The sub-type for tiny heap IDs depends on whether the heap ID is large enough to store objects + greater than 16 bytes or not. If the heap ID length is 18 bytes or smaller, the ‘normal’ + tiny heap ID form is used. If the heap ID length is greater than 18 bytes in length, the + “extended” form is used. See format description below for both sub-types.
HugeWhen the size of an object is larger than Maximum Size of Managed Objects in the + Fractal Heap Header, the object’s data is stored on its own in the file and the object + is tracked/indexed via a version 2 B-tree. All huge objects for a particular fractal heap use the same + v2 B-tree. All huge objects for a particular fractal heap use the same format for their huge object IDs. +
Depending on whether the IDs for a heap are large enough to hold the object’s retrieval + information and whether I/O pipeline filters are applied to the heap’s objects, 4 sub-types are + derived for huge object IDs for this heap: + + + + + + + + + + + + + + + + + + + + + +
Sub-typeDescription
Directly accessed, non-filteredThe object’s address and length are embedded in the fractal heap ID itself and the + object is directly accessed from them. This allows the object to be accessed without resorting + to the B-tree.
Directly accessed, filteredThe filtered object’s address, length, filter mask and de-filtered size are embedded + in the fractal heap ID itself and the object is accessed directly with them. This allows the + object to be accessed without resorting to the B-tree.
Indirectly accessed, non-filteredThe object is located by using a B-tree key embedded in the fractal heap ID to retrieve the + address and length from the version 2 B-tree for huge objects. Then, the address and length + are used to access the object.
Indirectly accessed, filteredThe object is located by using a B-tree key embedded in the fractal heap ID to retrieve the + filtered object’s address, length, filter mask and de-filtered size from the version + 2 B-tree for huge objects. Then, this information is used to access the object.
ManagedWhen the size of an object does not meet the above two conditions, the object is stored and managed + via the direct and indirect blocks based on the doubling table.
+ +The specific format for each type of heap ID is described below: + + + + + + + + + + + + + + + +
Layout: Fractal Heap ID for Tiny Objects (sub-type 1 - ‘Normal’)
bytebytebytebyte
Version, Type & LengthThis space inserted only to align table nicely

Data (variable size)
+ + + + + + + + + + + + + + + +
Fields: Fractal Heap ID for Tiny Objects (sub-type 1 - ‘Normal’)
Field NameDescription
Version, Type, and LengthThis is a bit field with the following definition: + + + + + + + + + + + + + + + + + +
BitDescription
6-7The current version of ID format. This document describes version 0.
4-5The ID type. Tiny objects have a value of 2. +
0-3The 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.
DataThis is the data for the object.
+ + + + + + + + + + + + + + + + + +
Layout: Fractal Heap ID for Tiny Objects (sub-type 2 - ‘Extended’)
bytebytebytebyte
Version, Type, and LengthExtended LengthThis space inserted only to align table nicely
Data (variable size)
+ + + + + + + + + + + + + + + + + + + +
Fields: Fractal Heap ID for Tiny Objects (sub-type 2 - ‘Extended’)
Field NameDescription
Version, Type, and LengthThis is a bit field with the following definition: + + + + + + + + + + + + + + + + + +
BitDescription
6-7The current version of ID format. This document describes version 0.
4-5The ID type. Tiny objects have a value of 2.
0-3These 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 LengthThis 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.
DataThis is the data for the object.
+ + + + + + + + + + + + + + + + +
Layout: Fractal Heap ID for Huge Objects (sub-type 1 & 2): indirectly accessed, + non-filtered/filtered
bytebytebytebyte
Version and TypeThis space inserted only to align table nicely

v2 B-tree KeyL (variable size)

+\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + +
Fields: Fractal Heap ID for Huge Objects (sub-type 1 & 2): indirectly accessed, + non-filtered/filtered
Field NameDescription
Version and TypeThis is a bit field with the following definition: + + + + + + + + + + + + + + + + + +
BitDescription
6-7The current version of ID format. This document describes version 0.
4-5The ID type. Huge objects have a value of 1.
0-3Reserved.
v2 B-tree KeyThis 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 @ref subsubsec_fmt3_infra_btrees_v2 + records sub-type 1 & 2 for a description of the fields. New key values are derived from Next + Huge Object ID in the Fractal Heap Header.
+ + + + + + + + + + + + + + + + + + + +
Layout: Fractal Heap ID for Huge Objects (sub-type 3): directly accessed, non-filtered
bytebytebytebyte
Version and TypeThis space inserted only to align table nicely

Address O


Length L

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + +
Fields: Fractal Heap ID for Huge Objects (sub-type 3): directly accessed, non-filtered
Field NameDescription
Version and TypeThis is a bit field with the following definition: + + + + + + + + + + + + + + + + + +
BitDescription
6-7The current version of ID format. This document describes version 0.
4-5The ID type. Huge objects have a value of 1.
0-3Reserved.
AddressThis field is the address of the object in the file.
LengthThis field is the length of the object in the file.
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Fractal Heap ID for Huge Objects (sub-type 4): directly accessed, filtered
bytebytebytebyte
Version and TypeThis space inserted only to align table nicely

Address O


Length L

Filter Mask

De-filtered Size L

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Fractal Heap ID for Huge Objects (sub-type 4): directly accessed, filtered
Field NameDescription
Version and TypeThis is a bit field with the following definition: + + + + + + + + + + + + + + + + + +
BitDescription
6-7The current version of ID format. This document describes version 0.
4-5The ID type. Huge objects have a value of 1.
0-3Reserved.
AddressThis field is the address of the filtered object in the file.
LengthThis field is the length of the filtered object in the file.
Filter MaskThis field is the I/O pipeline filter mask for the filtered object in the file.
Filtered SizeThis field is the size of the de-filtered object in the file.
+ + + + + + + + + + + + + + + + + + + +
Layout: Fractal Heap ID for Managed Objects
bytebytebytebyte
Version and TypeThis space inserted only to align table nicely
Offset (variable size)
Length (variable size)
+ + + + + + + + + + + + + + + + + + + +
Fields: Fractal Heap ID for Managed Objects
Field NameDescription
Version and TypeThis is a bit field with the following definition: + + + + + + + + + + + + + + + + + +
BitDescription
6-7The current version of ID format. This document describes version 0.
4-5The ID type. Managed objects have a value of 0.
0-3Reserved.
OffsetThis 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.
LengthThis 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.
+ +\subsection subsec_fmt3_infra_freespaceindex III.H. Disk Format: Level 1H - Free-space Index +Free-space managers are used to describe space within a heap or the entire HDF5 file that is not currently +used for that heap or file. + +The free-space manager header contains metadata information about the space being tracked, along +with the address of the list of free space sections which actually describes the free space. The +header records information about free-space sections being tracked, creation parameters for handling +free-space sections of a client, and section information used to locate the collection of free-space sections. + +The free-space section list stores a collection of free-space sections that is specific to each +client of the free-space manager. For example, the fractal heap is a client of the free space +manager and uses it to track unused space within the heap. There are 4 types of section records for the +fractal heap, each of which has its own format, listed below. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Free-space Manager Header
bytebytebytebyte
Signature
VersionClient IDThis space inserted only to align table nicely

Total Space TrackedL


Total Number of SectionsL


Number of Serialized SectionsL


Number of Un-Serialized SectionsL

Number of Section ClassesThis space inserted only to align table nicely
Shrink PercentExpand Percent
Size of Address SpaceThis space inserted only to align table nicely

Maximum Section Size L


Address of Serialized Section ListO


Size of Serialized Section List UsedL


Allocated Size of Serialized Section ListL

Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Free-space Manager Header
Field NameDescription
SignatureThe 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.
VersionThis is the version number for the Free-space Manager Header and this document describes version 0.
Client IDThis is the client ID for identifying the user of this free-space manager: + + + + + + + + + + + + + + + + + +
IDDescription
0Fractal heap
1File
2+Reserved.
Total Space TrackedThis is the total amount of free space being tracked, in bytes.
Total Number of SectionsThis is the total number of free-space sections being tracked.
Number of Serialized SectionsThis is the number of serialized free-space sections being tracked.
Number of Un-Serialized SectionsThis 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 ClassesThis is the number of section classes handled by this free space manager for the free-space client.
Shrink PercentThis is the percent of current size to shrink the allocated serialized free-space section list.
Expand PercentThis is the percent of current size to expand the allocated serialized free-space section list.
Size of Address SpaceThis is the size of the address space that free-space sections are within. This is stored as the + log2 of the actual value (in other words, the number of bits required to store values + within that address space).
Maximum Section SizeThis is the maximum size of a section to be tracked.
Address of Serialized Section ListThis is the address where the serialized free-space section list is stored.
Size of Serialized Section List UsedThis 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 ListThis is the size of serialized free-space section list actually allocated (in bytes).
ChecksumThis is the checksum for the free-space manager header.
+ +The free-space sections being managed are stored in a free-space section list, described below. +The sections in the free-space section list are stored in the following way: a count of the number of sections +describing a particular size of free space and the size of the free-space described (in bytes), followed +by a list of section description records; then another section count and size, followed by the list of +section descriptions for that size; and so on. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Free-space Section List
bytebytebytebyte
Signature
VersionThis space inserted only to align table nicely

Free-space Manager Header AddressO

Number of Section Records in Set \#0 (variable size)
Size of Free-space Section Described in Record Set \#0 (variable size)
Record Set \#0 Section Record \#0 Offset (variable size)
Record Set \#0 Section Record #0 TypeThis space inserted only to align table nicely
Record Set \#0 Section Record \#0 Data (variable size)
...
Record Set \#0 Section Record \#K-1 Offset (variable size)
Record Set \#0 Section Record \#K-1 TypeThis space inserted only to align table nicely
Record Set \#0 Section Record \#K-1 Data (variable size)
Number of Section Records in Set \#1 (variable size)
Size of Free-space Section Described in Record Set \#1 (variable size)
Record Set \#1 Section Record \#0 Offset (variable size)
Record Set \#1 Section Record \#0 TypeThis space inserted only to align table nicely
Record Set \#1 Section Record \#0 Data (variable size)
...
Record Set \#1 Section Record \#K-1 Offset (variable size)
Record Set \#1 Section Record \#K-1 TypeThis space inserted only to align table nicely
Record Set \#1 Section Record \#K-1 Data (variable size)
...
...
Number of Section Records in Set \#N-1 (variable size)
Size of Free-space Section Described in Record Set \#N-1 (variable size)
Record Set \#N-1 Section Record \#0 Offset (variable size)
Record Set \#N-1 Section Record \#0 TypeThis space inserted only to align table nicely
Record Set \#N-1 Section Record \#0 Data (variable size)
...
Record Set \#N-1 Section Record \#K-1 Offset (variable size)
Record Set \#N-1 Section Record \#K-1 TypeThis space inserted only to align table nicely
Record Set \#N-1 Section Record \#K-1 Data (variable size)
Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Free-space Section List
Field NameDescription
SignatureThe 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.
VersionThis is the version number for the Free-space Section List and this document describes version 0.
Free-space Manager Header AddressThis is the address of the Free-space Manager Header. This field is principally used for file + integrity checking.
Number of Section Records for Set \#NThis 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 \#NThis 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 OffsetThis 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 TypeThis 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: + + + + + + + + + + + + + +
TypeDescription
0File’s section (a range of actual bytes in file)
1+Reserved.
+
The defined record types for a fractal heap client are: + + + + + + + + + + + + + + + + + + + + + + + + + +
TypeDescription
0Fractal heap “single” section
1Fractal heap “first row” section
2Fractal heap “normal row” section
3Fractal heap “indirect” section
4+Reserved.
Record Set \#N Section \#K DataThis is the section-type specific information for each record in the record set, described below.
ChecksumThis is the checksum for the Free-space Section List.
+ +The section-type specific data for each free-space section record is described below: + + + + + +
Layout: File’s Section Data Record
No additional record data stored
+
+ + + + + +
Layout: Fractal Heap “Single” Section Data Record
No additional record data stored
+
+ + + + + +
Layout: Fractal Heap “First Row” Section Data Record
Same format as “indirect” section data
+
+ + + + + +
Layout: Fractal Heap “Normal Row” Section Data Record
No additional record data stored
+
+ + + + + + + + + + + + + + + + + + + +
Layout: Fractal Heap “Indirect” Section Data Record
bytebytebytebyte
Fractal Heap Indirect Block Offset (variable size)
Block Start RowBlock Start Column
Number of BlocksThis space inserted only to align table nicely
+ + + + + + + + + + + + + + + + + + + + + + + +
Fields: Fractal Heap “Indirect” Section Data Record
Field NameDescription
Fractal Heap Block OffsetThe 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 RowThis is the row that the empty blocks start in.
Block Start ColumnThis is the column that the empty blocks start in.
Number of BlocksThis is the number of empty blocks covered by the section.
+ +\subsection subsec_fmt3_infra_sohm III.I. Disk Format: Level 1I - Shared Object Header Message Table +The shared object header message table is used to locate object header messages that are shared +between two or more object headers in the file. Shared object header messages are stored and indexed in +the file in one of two ways: indexed sequentially in a shared header message list or indexed +with a v2 B-tree. The shared messages themselves are either stored in a fractal heap (when two or more +objects share the message), or remain in an object’s header (when only one object uses the message +currently, but the message can be shared in the future). + +The shared object header message table contains a list of shared message index headers. Each +index header records information about the version of the index format, the index storage type, flags +for the message types indexed, the number of messages in the index, the address where the index resides, +and the fractal heap address if shared messages are stored there. + +Each index can be either a list or a v2 B-tree and may transition between those two forms as the number +of messages in the index varies. Each shared message record contains information used to locate the +shared message from either a fractal heap or an object header. The types of messages that can be shared +are: Dataspace, Datatype, Fill Value, Filter Pipeline and Attribute. + +The shared object header message table is pointed to from a +@ref subsubsec_fmt3_dataobject_hdr_msg_shared message in the superblock extension for a file. This +message stores the version of the table format, along with the number of index headers in the table. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Shared Object Header Message Table
bytebytebytebyte
Signature
Version for index \#0Index Type for index #0Message Type Flags for index \#0
Minimum Message Size for index \#0
List Cutoff for index \#0v2 B-tree Cutoff for index \#0
Number of Messages for index \#0This space inserted only to align table nicely

Index AddressO for index \#0


Fractal Heap AddressO for index \#0

...
...
Version for index \#N-1Index Type for index \#N-1Message Type Flags for index \#N-1
Minimum Message Size for index \#N-1
List Cutoff for index \#N-1v2 B-tree Cutoff for index \#N-1
Number of Messages for index \#N-1This space inserted only to align table nicely

Index AddressO for index \#N-1


Fractal Heap AddressO for index \#N-1

Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Shared Object Header Message Table
Field NameDescription
SignatureThe 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 \#NThis is the version number for the list of shared object header message indexes and this document + describes version 0.
Index Type for index \#NThe type of index can be an unsorted list or a v2 B-tree.
Message Type Flags for index \#NThis field indicates the type of messages tracked in the index, as follows: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BitsDescription
0If set, the index tracks Dataspace Messages.
1If set, the message tracks Datatype Messages.
2If set, the message tracks Fill Value Messages.
3If set, the message tracks Filter Pipeline Messages.
4If set, the message tracks Attribute Messages.
5-15Reserved (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 \#NThis 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 \#NThis 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 \#NThis 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 \#NThe number of shared messages being tracked for the index.
Index Address for index \#NThis field is the address of the list or v2 B-tree where the index nodes reside.
Fractal Heap Address for index \#NThis field is the address of the fractal heap if shared messages are stored there.
ChecksumThis is the checksum for the table.
+ +Shared messages are indexed either with a shared message record list, described below, +or using a v2 B-tree (using record type 7). The number of records in the shared message record +list is determined in the index’s entry in the shared object header message table. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Shared Message Record List
bytebytebytebyte
Signature
Shared Message Record \#0
Shared Message Record \#1
...
Shared Message Record \#N-1
Checksum
+ + + + + + + + + + + + + + + + + + + +
Fields: Shared Message Record List
Field NameDescription
SignatureThe 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 \#NThe record for locating the shared message, either in the fractal heap for the index, or an object + header (see format for index nodes below).
ChecksumThis is the checksum for the list.
+ +The record for each shared message in an index is stored in one of the following forms: + + + + + + + + + + + + + + + + + + + + + +
Layout: Shared Message Record, for Messages Stored in a Fractal Heap
bytebytebytebyte
Message LocationThis space inserted only to align table nicely
Hash Value
Reference Count

Fractal Heap ID

+ + + + + + + + + + + + + + + + + + + + + + + +
Fields: Shared Message Record, for Messages Stored in a Fractal Heap
Field NameDescription
Message LocationThis has a value of 0 indicating that the message is stored in the heap.
Hash ValueThis is the hash value for the message.
Reference CountThis is the number of times the message is used in the file.
Fractal Heap IDThis is an 8-byte fractal heap ID for the message as stored in the fractal heap for the index.
+ + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Shared Message Record, for Messages Stored in an Object Header
bytebytebytebyte
Message LocationThis space inserted only to align table nicely
Hash Value
ReservedMessage TypeCreation Index

Object Header AddressO

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Shared Message Record, for Messages Stored in an Object Header
Field NameDescription
Message LocationThis has a value of 1 indicating that the message is stored in an object header.
Hash ValueThis is the hash value for the message.
Message TypeThis is the message type in the object header.
Creation IndexThis is the creation index of the message within the object header.
Object Header AddressThis is the address of the object header where the message is located.
+ +\section sec_fmt3_dataobject IV. Disk Format: Level 2 - Data Objects +Data objects contain the “real” user-visible information in the file. These objects compose +the scientific data and other information which are generally thought of as “data” by the +end-user. All the other information in the file is provided as a framework for storing and accessing +these data objects. + +A data object is composed of header and data information. The header information contains the +information needed to interpret the data information for the object as well as additional “metadata” +or pointers to additional “metadata” used to describe or annotate each object. + +\subsection subsec_fmt3_dataobject_hdr IV.A. Disk Format: Level 2A - Data Object Headers +The header information of an object is designed to encompass all the information about an object, except for +the data itself. This information includes the dataspace, datatype, information about how the data is stored +on disk (in external files, compressed, broken up in blocks, and so on), as well as other information used by the +library to speed up access to the data objects or maintain a file’s integrity. Information stored by user +applications as attributes is also stored in the object’s header. The header of each object is not necessarily +located immediately prior to the object’s data in the file and in fact may be located in any position in the +file. The order of the messages in an object header is not significant. + +Object headers are composed of a prefix and a set of messages. The prefix contains the information needed to +interpret the messages and a small amount of metadata about the object, and the messages contain the majority +of the metadata about the object. + +\subsection subsec_fmt3_dataobject_hdr_prefix IV.A.1 Disk Format: Level 2A1 - Data Object Header Prefix + +\subsubsection subsubsec_fmt3_dataobject_hdr_prefix_one IV.A.1.a Version 1 Data Object Header Prefix +Header messages are aligned on 8-byte boundaries for version 1 object headers. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Version 1 Object Header
bytebytebytebyte
VersionReserved (zero)Total Number of Header Messages
Object Reference Count
Object Header Size
Reserved (zero)
Header Message Type \#1Size of Header Message Data \#1
Header Message \#1 FlagsReserved (zero)

Header Message Data \#1

.
.
.
Header Message Type \#nSize of Header Message Data \#n
Header Message \#n FlagsReserved (zero)

Header Message Data \#n

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 1 Object Header
Field NameDescription
VersionThis 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 MessagesThis 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 CountThis 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 SizeThis 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 TypeThis 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 DataThis 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 FlagsThis is a bit field with the following definition: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BitDescription
0If set, the message data is constant. This is used for messages like the datatype message of + a dataset.
1If 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 @ref + subsec_fmt3_dataobject_hdr_msg section below) and the Size of Header Message Data field contains + the size of that Shared Message.
2If set, the message should not be shared.
3If 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)
4If 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)
5If 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)
6If set, this message is shareable.
7If 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 DataThe 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 zeros to make the size a multiple of + eight.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_prefix_two IV.A.1.b Version 2 Data Object Header Prefix +Note that the “total number of messages” field has been dropped from the data object header +prefix in this version. The number of messages in the data object header is just determined by the +messages encountered in all the object header blocks. + +Note also that the fields and messages in this version of data object headers have no alignment +or padding bytes inserted - they are stored packed together. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Version 2 Object Header
bytebytebytebyte
Signature
VersionFlagsThis space inserted only to align table nicely
Access time (optional)
Modification Time (optional)
Change Time (optional)
Birth Time (optional)
Maximum \# of compact attributes (optional)Minimum \# of dense attributes (optional)
Size of Chunk \#0 (variable size)This space inserted only to align table nicely
Header Message Type \#1Size of Header Message Data \#1Header Message \#1 Flags
Header Message \#1 Creation Order (optional)This space inserted only to align table nicely

Header Message Data \#1

.
.
.
Header Message Type \#nSize of Header Message Data \#nHeader Message \#n Flags
Header Message \#n Creation Order (optional)This space inserted only to align table nicely

Header Message Data \#n

Gap (optional, variable size)
Checksum
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 2 Object Header
Field NameDescription
SignatureThe 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.
VersionThis field has a value of 2 indicating version 2 of the object header.
FlagsThis field is a bit field indicating additional information about the object header. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Bit(s)Description
0-1This two bit field determines the size of the Size of Chunk \#0 field. The values are: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0The Size of Chunk \#0 field is 1 byte.
1The Size of Chunk \#0 field is 2 bytes.
2The Size of Chunk \#0 field is 4 bytes.
3The Size of Chunk \#0 field is 8 bytes.
2If set, attribute creation order is tracked.
3If set, attribute creation order is indexed.
4If set, non-default attribute storage phase change values are stored.
5If set, access, modification, change and birth times are stored.
6-7Reserved
Access TimeThis 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 TimeThis 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 TimeThis 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 TimeThis 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 attributesThis 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 attributesThis 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 \#0This 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 TypeSame format as version 1 of the object header, described above.
Size of Header Message \#n DataThis 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 FlagsSame format as version 1 of the object header, described above.
Header Message \#n Creation OrderThis 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 DataSame format as version 1 of the object header, described above.
GapA 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.
ChecksumThis is the checksum for the object header chunk.
+ +The header message types and the message data associated with them compose the critical "meta-data" about +each object. Some header messages are required for each object while others are optional. Some optional +header messages may also be repeated several times in the header itself, the requirements and number of +times allowed in the header will be noted in each header message description below. + +\subsection subsec_fmt3_dataobject_hdr_msg IV.A.2 Disk Format: Level 2A2 - Data Object Header Messages +Data object header messages are small pieces of metadata that are stored in the data object header for +each object in an HDF5 file. Data object header messages provide the metadata required to describe an +object and its contents, as well as optional pieces of metadata that annotate the meaning or purpose of +the object. + +Data object header messages are either stored directly in the data object header for the object or are +shared between multiple objects in the file. When a message is shared, a flag in the Message Flags +indicates that the actual Message Data portion of that message is stored in another location +(such as another data object header, or a heap in the file) and the Message Data field +contains the information needed to locate the actual information for the message. + +The format of shared message data is described here: + + + + + + + + + + + + + + + + + + + +
Layout: Shared Message (Version 1)
bytebytebytebyte
VersionTypeReserved (zero)
Reserved (zero)

AddressO

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + +
Fields: Shared Message (Version 1)
Field NameDescription
VersionThe version number is used when there are changes in the format of a shared object message and is + described here: + + + + + + + + + + + + + +
VersionDescription
0Never used.
1Used by the library before version 1.6.1.
TypeThe type of shared message location: + + + + + + + + + +
ValueDescription
0Message stored in another object’s header (a committed message).
AddressThe address of the object header containing the message to be shared.
+ + + + + + + + + + + + + + + + + +
Layout: Shared Message (Version 2)
bytebytebytebyte
VersionTypeThis space inserted only to align table nicely

AddressO

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + +
Fields: Shared Message (Version 2)
Field NameDescription
VersionThe version number is used when there are changes in the format of a shared object message and is + described here: + + + + + + + + + +
VersionDescription
2Used by the library of version 1.6.1 and after.
TypeThe type of shared message location: + + + + + + + + + +
ValueDescription
0Message stored in another object’s header (a committed message).
AddressThe address of the object header containing the message to be shared.
+ + + + + + + + + + + + + + + + + +
Layout: Shared Message (Version 3)
bytebytebytebyte
VersionTypeThis space inserted only to align table nicely
Location (variable size)
+ + + + + + + + + + + + + + + + + + + +
Fields: Shared Message (Version 3)
Field NameDescription
VersionThe version number indicates changes in the format of shared object message and is described here: + + + + + + + + + +
VersionDescription
3Used 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.
TypeThe type of shared message location: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0Message is not shared and is not shareable.
1Message stored in file’s shared object header message heap + (a shared message).
2Message stored in another object’s header (a committed message).
3Message stored is not shared, but is shareable.
LocationThis field contains either a @ref FMT3SizeOfOffsetsV0 "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.
+ +The following is a list of currently defined header messages: + +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_nil IV.A.2.a. The NIL Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: NIL
Header Message Type: 0x0000
Length: Varies
Status: Optional; may be repeated.
Description:The NIL message is used to indicate a message which is to be ignored when reading the header messages + for a data object. [Possibly one which has been deleted for some reason.]
Format of Data: Unspecified
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_simple IV.A.2.b. The Dataspace Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Dataspace
Header Message Type: 0x0001
Length: Varies according to the number of dimensions, as described in the following + table.
Status: Required for dataset objects; may not be repeated.
Description:The dataspace message describes the number of dimensions (in other words, “rank”) and size + of each dimension that the data object has. This message is only used for datasets which have a + simple, rectilinear, array-like layout; datasets requiring a more complex layout are not yet supported.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Dataspace Message - Version 1
bytebytebytebyte
VersionDimensionalityFlagsReserved
Reserved
Dimension \#1 SizeL

.
.
.

Dimension \#n SizeL


Dimension \#1 Maximum SizeL

.
.
.

Dimension \#n Maximum SizeL


Permutation Index \#1L

.
.
.

Permutation Index \#nL

+\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Dataspace Message - Version 1
Field NameDescription
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)).
DimensionalityThis value is the number of dimensions that the data object has.
FlagsThis 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 SizeThis 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 SizeThis value is the maximum size of the dimension of the data as stored in the file. This value may be + the special “@ref FMT3UnlimitedDim "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 \#nThis 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 2 of the dataspace message dropped the optional permutation index value support, as it was never +implemented in the HDF5 Library: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Dataspace Message - Version 2
bytebytebytebyte
VersionDimensionalityFlagsType
Dimension \#1 SizeL

.
.
.

Dimension \#n SizeL


Dimension \#1 Maximum SizeL

.
.
.

Dimension \#n Maximum SizeL

+\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Dataspace Message - Version 2
Field NameDescription
Version This value is used to determine the format of the Dataspace Message. This field should be ‘2’ + for version 2 format messages.
DimensionalityThis value is the number of dimensions that the data object has.
FlagsThis 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.
Typeindicates the type of the dataspace: + + + + + + + + + + + + + + + + + +
ValueDescription
0A scalar dataspace; in other words, a dataspace with a single, dimensionless element.
1A simple dataspace; in other words, a dataspace with a rank > 0 and an appropriate number + of dimensions.
2A null dataspace; in other words, a dataspace with no elements.
Dimension \#n SizeThis 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 SizeThis value is the maximum size of the dimension of the data as stored in the file. This value may be + the special “@ref FMT3UnlimitedDim "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.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_linkinfo IV.A.2.c. The Link Info Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Link Info
Header Message Type: 0x002
Length: Varies
Status: Optional; may not be repeated.
Description:The link info message tracks variable information about the current state of the links for a + “new style” group’s behavior. Variable information will be stored in this + message and constant information will be stored in the @ref + subsubsec_fmt3_dataobject_hdr_msg_groupinfo message.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Link Info
bytebytebytebyte
VersionFlagsThis space inserted only to align table nicely

Maximum Creation Index (8 bytes, optional)


Fractal Heap AddressO


Address of v2 B-tree for Name IndexO


Address of v2 B-tree for Creation Order IndexO (optional)

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Link Info
Field NameDescription
VersionThe version number for this message. This document describes version 0.
FlagsThis field determines various optional aspects of the link info message: + + + + + + + + + + + + + + + + + +
BitDescription
0If set, creation order for the links is tracked.
1If set, creation order for the links is indexed.
2-7Reserved
Maximum Creation IndexThis 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 AddressThis is the address of the fractal heap to store dense links. Each link stored in the fractal heap + is stored as a @ref subsubsec_fmt3_dataobject_hdr_msg_link.
+ 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 @ref FMT3UndefinedAddress "undefined address".
Address of v2 B-tree for Name IndexThis 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 @ref FMT3UndefinedAddress "undefined address".
Address of v2 B-tree for Creation Order IndexThis 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 @ref FMT3UndefinedAddress "undefined address".
+ This field exists if bit 1 of flags is set.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_dtmessage IV.A.2.d. The Datatype Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Datatype
Header Message Type: 0x0003
Length: Variable
Status: Required for dataset or committed datatype (formerly named datatype) + objects; may not be repeated.
Description:The datatype message defines the datatype for each element of a dataset or a common datatype for + sharing between multiple datasets. A datatype can describe an atomic type like a fixed- or + floating-point type or more complex types like a C struct (compound datatype), array (array datatype) + or C++ vector (variable-length datatype).
+ Datatype messages that are part of a dataset object do not describe how elements are related to one + another; the dataspace message is used for that purpose. Datatype messages that are part of a committed + datatype (formerly named datatype) message describe a common datatype that can be shared by multiple + datasets in the file.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + +
Layout: Datatype Message
bytebytebytebyte
Class and VersionClass Bit Field, Bits 0-7Class Bit Field, Bits 8-15Class Bit Field, Bits 16-23
Size


Properties

/
+ + + + + + + + + + + + + + + + + + + + + + + +
Fields: Datatype Message
Field NameDescription
Class and VersionThe 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: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
VersionDescription
0Never used
1Used by early versions of the library to encode compound datatypes with explicit array fields. + See the compound datatype description below for further details.
2Used when an array datatype needs to be encoded.
3Used when a VAX byte-ordered type needs to be encoded. Packs various other datatype classes more + efficiently also.
4Used to encode the revised reference datatype.
5Used when a complex number datatype needs to be encoded.

+ 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: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0\ref FMT3ClassFixedPoint "Fixed-Point"
1\ref FMT3ClassFloatingPoint "Floating-Point"
2\ref FMT3ClassTime "Time"
3\ref FMT3ClassString "String"
4\ref FMT3ClassBitField "Bit field"
5\ref FMT3ClassOpaque "Opaque"
6\ref FMT3ClassCompound "Compound"
7\ref FMT3ClassReference "Reference"
8\ref FMT3ClassEnum "Enumerated"
9\ref FMT3ClassVarLen "Variable-Length"
10\ref FMT3ClassArray "Array"
11\ref FMT3ClassComplex "Complex"
Class Bit FieldsThe 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.
SizeThe size of a datatype element in bytes.
PropertiesThis 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.
+ +\anchor FMT3ClassFixedPoint

Class specific information for Fixed-Point Numbers (Class 0):

+ + + + + + + + + + + + + + + + + + + + + + +
Bits: Fixed-point Bit Field Description
BitsMeaning
0Byte Order. If zero, byte order is little-endian; otherwise, byte order is big endian.
1, 2Padding type. Bit 1 is the lo_pad type and bit 2 is the hi_pad type. If a datum has + unused bits at either end, then the lo_pad or hi_pad bit is copied to those locations.
3Signed. If this bit is set then the fixed-point number is in 2’s complement form.
4-23Reserved (zero).
+ + + + + + + + + + + + + +
Layout: Fixed-Point Property Descriptions
ByteByteByteByte
Bit OffsetBit Precision
+ + + + + + + + + + + + + + + +
Fields: Fixed-Point Property Descriptions
Field NameDescription
Bit OffsetThe bit offset of the first significant bit of the fixed-point value within the datatype. The + bit offset specifies the number of bits “to the right of” the value (which are + set to the lo_pad bit value).
Bit PrecisionThe number of bits of precision of the fixed-point value within the datatype. This value, + combined with the datatype element’s size and the Bit Offset field specifies the number + of bits “to the left of” the value (which are set to the hi_pad bit value).
+ +\anchor FMT3ClassFloatingPoint

Class specific information for Floating-Point Numbers (Class 1):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Bits: Floating-Point Bit Field Description
BitsMeaning
0Byte Order. These two non-contiguous bits specify the “endianness” of + the bytes in the datatype element. + + + + + + + + + + + + + + + + + + + + + + + + + + +
Bit 6Bit 0Description
00Byte order is little-endian
01Byte order is big-endian
10Reserved
11Byte order is VAX-endian
1, 2, 3Padding type. Bit 1 is the low bits pad type, bit 2 is the high bits pad type, and bit + 3 is the internal bits pad type. If a datum has unused bits at either end or between the sign bit, exponent, + or mantissa, then the value of bit 1, 2, or 3 is copied to those locations.
4-5Mantissa Normalization. This 2-bit bit field specifies how the most significant bit of + the mantissa is managed. + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0No normalization
1The most significant bit of the mantissa is always set (except for 0.0).
2The most significant bit of the mantissa is not stored, but is implied to be set.
3Reserved.
6-7Reserved (zero).
8-15Sign Location. This is the bit position of the sign bit. Bits are numbered with the least + significant bit zero.
16-23Reserved (zero).
+ + + + + + + + + + + + + + + + + + + + + + +
Layout: Floating-Point Property Description
ByteByteByteByte
Bit OffsetBit Precision
Exponent LocationExponent SizeMantissa LocationMantissa Size
Exponent Bias
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Floating-Point Property Description
Field NameProperty Description
Bit OffsetThe bit offset of the first significant bit of the floating-point value within the datatype. The + bit offset specifies the number of bits “to the right of” the value.
Bit PrecisionThe number of bits of precision of the floating-point value within the datatype.
Exponent LocationThe bit position of the exponent field. Bits are numbered with the least significant + bit number zero.
Exponent SizeThe size of the exponent field in bits.
Mantissa LocationThe bit position of the mantissa field. Bits are numbered with the least significant bit number + zero.
Mantissa SizeThe size of the mantissa field in bits.
Exponent BiasThe bias of the exponent field.
+ +\anchor FMT3ClassTime

Class specific information for Time (Class 2):

+ + + + + + + + + + + + + + +
Bits: Time Bit Field Description
BitsMeaning
0Byte Order. If zero, byte order is little-endian; otherwise, byte order is big endian.
1-23Reserved (zero).
+
+ + + + + + + + + + +
Layout: Time Property Description
ByteByte
Bit Precision
+
+ + + + + + + + + + + +
Fields: Time Property Description
Field NameDescription
Bit PrecisionThe number of bits of precision of the time value.
+
+ +\anchor FMT3ClassString

Class specific information for Strings (Class 3):

+ + + + + + + + + + + + + + + + + +
Bits: String Bit Field Description
BitsMeaning
0-3Padding type. This four-bit value determines the type of padding to use for the + string. The values are: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0Null Terminate: A zero byte marks the end of the string and is guaranteed to be present after + converting a long string to a short string. When converting a short string to a long string the + value is padded with additional null characters as necessary.
1Null Pad: Null characters are added to the end of the value during conversions from short values + to long values but conversion in the opposite direction simply truncates the value.
2Space Pad: Space characters are added to the end of the value during conversions from short values + to long values but conversion in the opposite direction simply truncates the value. This is the + Fortran representation of the string.
3-15Reserved.
+
4-7Character Set. The character set used to encode the string. + + + + + + + + + + + + + + + + + +
ValueDescription
0ASCII character set encoding
1UTF-8 character set encoding
2-15Reserved
8-23Reserved (zero).
+ +There are no properties defined for the string class. + +\anchor FMT3ClassBitField

Class specific information for Bitfields (Class 4):

+ + + + + + + + + + + + + + + + + + +
Bits: Bitfield Bit Field Description
BitsMeaning
0Byte Order. If zero, byte order is little-endian; otherwise, byte order is big endian.
1, 2Padding type. Bit 1 is the lo_pad type and bit 2 is the hi_pad type. If a datum has + unused bits at either end, then the lo_pad or hi_pad bit is copied to those locations.
3-23Reserved (zero).
+ + + + + + + + + + + + + +
Layout: Bit Field Property Description
ByteByteByteByte
Bit OffsetBit Precision
+ + + + + + + + + + + + + + + +
Fields: Bit Field Property Description
Field NameDescription
Bit OffsetThe bit offset of the first significant bit of the bitfield within the datatype. The bit + offset specifies the number of bits “to the right of” the value.
Bit PrecisionThe number of bits of precision of the bit field within the datatype.
+ +\anchor FMT3ClassOpaque

Class specific information for Opaque (Class 5):

+ + + + + + + + + + + + + + +
Bits: Opaque Bit Field Description
BitsMeaning
0-7Length of ASCII tag in bytes.
8-23Reserved (zero).
+ + + + + + + + + + + + +
Layout: Opaque Property Description
ByteByteByteByte

ASCII Tag

+ + + + + + + + + + + +
Fields: Opaque Property Description
Field NameDescription
ASCII TagThis NUL-terminated string provides a description for the opaque type. It is NUL-padded to a + multiple of 8 bytes.
+ +\anchor FMT3ClassCompound

Class specific information for Compound Types (Class 6):

+ + + + + + + + + + + + + + +
Bits: Compound Bit Field Description
BitsMeaning
0-15Number of Members. This field contains the number of members defined for the + compound datatype. The member definitions are listed in the Properties field of the data type + message.
16-23Reserved (zero).
+ +The Properties field of a compound datatype is a list of the member definitions of the compound datatype. +The member definitions appear one after another with no intervening bytes. The member types are described +with a (recursively) encoded datatype message. + +Note that the property descriptions are different for different versions of the datatype version. Additionally +note that the version 0 properties are deprecated and has been replaced with later encodings in +versions of the HDF5 library from the 1.4 release onward. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Compound Properties Description for Datatype Version 1
ByteByteByteByte


Name

/
Byte Offset of Member
DimensionalityReserved (zero)
Dimension Permutation
Reserved (zero)
Dimension \#1 Size (required)
Dimension \#2 Size (required)
Dimension \#3 Size (required)
Dimension \#4 Size (required)

Member Type Message

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Compound Properties Description for Datatype Version 1
Field NameDescription
NameThis NUL-terminated string provides a description for the opaque type. It is NUL-padded to a + multiple of 8 bytes.
Byte Offset of MemberThis is the byte offset of the member within the datatype.
DimensionalityIf set to zero, this field indicates a scalar member. If set to a value greater than zero, + this field indicates that the member is an array of values. For array members, the size of + the array is indicated by the ‘Size of Dimension n’ field in this message.
Dimension PermutationThis field was intended to allow an array field to have its dimensions permuted, but this was + never implemented. This field should always be set to zero.
Dimension \#n SizeThis field is the size of a dimension of the array field 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.
Member Type MessageThis field is a datatype message describing the datatype of the member.
+ + + + + + + + + + + + + + + + + + +
Layout: Compound Properties Description for Datatype Version 2
ByteByteByteByte

Name

Byte Offset of Member

Member Type Message

+ + + + + + + + + + + + + + + + + + + +
Fields: Compound Properties Description for Datatype Version 2
Field NameDescription
NameThis NUL-terminated string provides a description for the opaque type. It is NUL-padded to a multiple + of 8 bytes.
Byte Offset of MemberThis is the byte offset of the member within the datatype.
Member Type MessageThis field is a datatype message describing the datatype of the member.
+ + + + + + + + + + + + + + + + + + +
Layout: Compound Properties Description for Datatype Version 3
ByteByteByteByte

Name

Byte Offset of Member

Member Type Message

+ + + + + + + + + + + + + + + + + + + +
Fields: Compound Properties Description for Datatype Version 3
Field NameDescription
NameThis NUL-terminated string provides a description for the opaque type. It is not NUL-padded to a + multiple of 8 bytes.
Byte Offset of MemberThis is the byte offset of the member within the datatype. The field size is the minimum number of bytes + necessary, based on the size of the datatype element. For example, a datatype element size of less than + 256 bytes uses a 1 byte length, a datatype element size of 256-65535 bytes uses a 2 byte length, and + so on.
Member Type MessageThis field is a datatype message describing the datatype of the member.
+ +\anchor FMT3ClassReference

Class specific information for Reference (Class 7):


+Note that for region references, the stored data is a \ref FMT3GlobalHeapID "Global Heap ID" pointing to information +about the region stored in the global heap. + + + + + + + + + + + + + + + +
Bits: Reference Bit Field Description for Datatype Version < 4
BitsMeaning
0-3Type. This four-bit value contains the reference types which are supported + for backward compatibility. The values defined are: + + + + + + + + + + + + + + + + + +
ValueDescription
0Object Reference (#H5R_OBJECT1): A reference to another object in this HDF5 file.
1Dataset Region Reference (#H5R_DATASET_REGION1): A reference to a region within a dataset + in this HDF5 file.
2-15Reserved
4-23Reserved (zero).
+ + + + + + + + + + + + + + + + + + + +
Bits: Reference Bit Field Description for Datatype Version 4
BitsMeaning
0-3Type. This four-bit value contains the revised reference types. The values + defined are: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
2Object Reference (#H5R_OBJECT2): A reference to another object in this file or an + external file.
3Dataset Region Reference (#H5R_DATASET_REGION2): A reference to a region within a + dataset in this file or an external file.
4Attribute Reference (#H5R_ATTR): A reference to an attribute attached to an object + in this file or an external file.
5-15Reserved
+
4-7Version. This four-bit value contains the version for encoding the revised + reference types. The values defined are: + + + + + + + + + + + + + + + + + +
ValueDescription
0Unused
1The version for encoding the revised reference types: Object Reference (2), + Dataset Region Reference (3) and Attribute Reference (4).
2-15Reserved
8-23Reserved (zero).
+ +There are no properties defined for the reference class. + +\anchor FMT3ClassEnum

Class specific information for Enumeration (Class 8):

+ + + + + + + + + + + + + + +
Bits: Enumeration Bit Field Description
BitsMeaning
0-15Number of Members. The number of name/value pairs defined for the enumeration type.
16-23Reserved (zero).
+ + + + + + + + + + + + + + + + + + +
Layout: Enumeration Property Description for Datatype Versions 1 and 2
ByteByteByteByte

Base Type
/

Names


Values

+ + + + + + + + + + + + + + + + + + + +
Fields: Enumeration Property Description for Datatype Versions 1 and 2
Field NameDescription
Base TypeEach enumeration type is based on some parent type, usually an integer. The information + for that parent type is described recursively by this field.
NamesThe name for each name/value pair. Each name is stored as a null terminated ASCII string + in a multiple of eight bytes. The names are in no particular order.
ValuesThe list of values in the same order as the names. The values are packed (no inter-value + padding) and the size of each value is determined by the parent type.
+ + + + + + + + + + + + + + + + + + +
Layout: Enumeration Property Description for Datatype Versions 3
ByteByteByteByte

Base Type
/

Names


Values

+ + + + + + + + + + + + + + + + + + + +
Fields: Enumeration Property Description for Datatype Versions 3
Field NameDescription
Base TypeEach enumeration type is based on some parent type, usually an integer. The information + for that parent type is described recursively by this field.
NamesThe name for each name/value pair. Each name is stored as a null terminated ASCII string, + not padded to a multiple of eight bytes. The names are in no particular order.
ValuesThe list of values in the same order as the names. The values are packed (no inter-value + padding) and the size of each value is determined by the parent type.
+ +\anchor FMT3ClassVarLen

Class specific information for Variable-Length (Class 9):

+ + + + + + + + + + + + + + + + + + + + + + +
Bits: Variable-Length Bit Field Description
BitsMeaning
0-3Type. This four-bit value contains the type of variable-length datatype described. + The values defined are: + + + + + + + + + + + + + + + + + +
ValueDescription
0Sequence: A variable-length sequence of any datatype. Variable-length sequences do not + have padding or character set information.
1String: A variable-length sequence of characters. Variable-length strings have padding and + character set information.
2-15Reserved
4-7Padding type. (variable-length string only). This four-bit value determines the + type of padding used for variable-length strings. The values are the same as for the string padding + type, as follows: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
00 Null terminate: A zero byte marks the end of a string and is guaranteed to be present after + converting a long string to a short string. When converting a short string to a long string, + the value is padded with additional null characters as necessary.
1Null pad: Null characters are added to the end of the value during conversion from a short string to + a longer string. Conversion from a long string to a shorter string simply truncates the value.
2Space pad: Space characters are added to the end of the value during conversion from a short string + to a longer string. Conversion from a long string to a shorter string simply truncates the value. + This is the Fortran representation of the string.
3-15Reserved
+ This value is set to zero for variable-length sequences.
8-11Character Set. (variable-length string only) This four-bit value specifies the + character set to be used for encoding the string: + + + + + + + + + + + + + + + + + +
ValueDescription
0ASCII character set encoding.
1UTF-8 character set encoding.
2-15Reserved
+ This value is set to zero for variable-length sequences.
12-23Reserved (zero).
+ + + + + + + + + + + + +
Layout: Variable-Length Property Description
ByteByteByteByte

Parent Type Message

+ + + + + + + + + + + +
Fields: Variable-Length Property Description
Field NameDescription
Parent TypeEach variable-length type is based on some parent type. This field contains the datatype + message describing that parent type. In the case of nested variable-length types, this parent + datatype message will recursively contain all parent datatype messages. Variable-length strings + are considered to have the parent type #H5T_NATIVE_UCHAR.
+ +\anchor FMT3ClassArray

Class specific information for Array (Class 10):

+ +There are no bit fields defined for the array class. + +Note that the dimension information defined in the property for this datatype class is independent of +dataspace information for a dataset. The dimension information here describes the dimensionality of the +information within a data element (or a component of an element, if the array datatype is nested within +another datatype) and the dataspace for a dataset describes the location of the elements in a dataset. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Array Property Description for Datatype Version 2
ByteByteByteByte
DimensionalityReserved (zero)
Dimension \#1 Size
.
.
.
Dimension \#n Size
Permutation Index \#1
.
.
.
Permutation Index \#n

Base Type

+ + + + + + + + + + + + + + + + + + + + + + + +
Fields: Array Property Description for Datatype Version 2
Field NameDescription
DimensionalityThis value is the number of dimensions that the array has.
Dimension \#n SizeThis value is the size of the dimension of the array 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.
Permutation Index \#nThis value is the index permutation used to map each dimension from the canonical representation + to an alternate axis for each dimension. Currently, dimension permutations are not supported and + these indices should be set to the index position minus one (i.e. the first dimension should be + set to 0, the second dimension should be set to 1, and so on.)
Base TypeEach array type is based on some parent type. The information for that parent type is described + recursively by this field.
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Array Property Description for Datatype Version 3
ByteByteByteByte
DimensionalityThis space inserted only to align table nicely
Dimension \#1 Size
.
.
.
Dimension \#n Size

Base Type

+ + + + + + + + + + + + + + + + + + + +
Fields: Array Property Description for Datatype Version 3
Field NameDescription
DimensionalityThis value is the number of dimensions that the array has.
Dimension \#n SizeThis value is the size of the dimension of the array 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.
Base TypeEach array type is based on some parent type. The information for that parent type is described + recursively by this field.
+ +\anchor FMT3ClassComplex

Class specific information for the Complex class (Class 11):

+ + + + + + + + + + + + + + + + + + +
Bits: Complex Bit Field Description
BitsMeaning
0Homogeneous. If zero, each part of the complex number + datatype is a different floating point datatype (heterogeneous). + Otherwise, each part of the complex number datatype is the same + floating point datatype (homogeneous). Currently, only homogeneous + complex number datatypes are supported.
1,2Complex number form. This two-bit value contains the type of complex number datatype + described. The values defined are: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0Rectangular
1Polar
2Exponential
3Reserved
+ Currently, only rectangular complex number datatypes are supported.
3-23Reserved (zero).
+ + + + + + + + + + + + +
Layout: Complex Property Description
ByteByteByteByte

Parent Type Message

+ + + + + + + + + + + +
Fields: Complex Property Description
Field NameDescription
Parent Type MessageEach complex number type is based on a parent floating point type. This field contains the + datatype message describing that parent type.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_ofvmessage IV.A.2.e. Data Storage - Fill Value (Old) Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Fill Value (old)
Header Message Type: 0x0004
Length: Varies
Status: Optional; may not be repeated.
Description:The fill value message stores a single data value which is returned to the application when an + uninitialized data element is read from a dataset. The fill value is interpreted with the same + datatype as the dataset. If no fill value message is present then a fill value of all zero bytes + is assumed.
+ This fill value message is deprecated in favor of the “new” fill value message (Message + Type 0x0005) and is only written to the file for forward compatibility with versions of the HDF5 + Library before the 1.6.0 version. Additionally, it only appears for datasets with a user-defined + fill value (as opposed to the library default fill value or an explicitly set “undefined” + fill value).
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + +
Layout: Fill Value Message (Old)
bytebytebytebyte
Size (4 bytes)

Fill Value (optional, variable size)

+
+ + + + + + + + + + + + + + +
Fields: Fill Value Message (Old)
Field NameDescription
SizeThis is the size of the Fill Value field in bytes.
Fill ValueThe fill value. The bytes of the fill value are interpreted using the same datatype as for the dataset.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_fvmessage IV.A.2.f. The Data Storage - Fill Value Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Fill Value
Header Message Type: 0x0005
Length: Varies
Status: Required for dataset objects; may not be repeated.
Description:The fill value message stores a single data value which is returned to the application when an + uninitialized data element is read from a dataset. The fill value is interpreted with the same + datatype as the dataset.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + +
Layout: Fill Value Message - Versions 1 & 2
bytebytebytebyte
VersionSpace Allocation TimeFill Value Write TimeFill Value Defined
Size (optional)

Fill Value (optional, variable size)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Fill Value Message - Versions 1 & 2
Field NameDescription
VersionThe version number information is used for changes in the format of the fill value message and + is described here: + + + + + + + + + + + + + + + + + + + + + +
VersionDescription
0Never used
1Initial version of this message.
2In this version, the Size and Fill Value fields are only present if the Fill Value Defined + field is set to 1.
3This version packs the other fields in the message more efficiently than version 2.
+
Space Allocation TimeWhen the storage space for the dataset’s raw data will be allocated. The allowed values are: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0Not used
1Early allocation. Storage space for the entire dataset should be allocated in the file + when the dataset is created.
2Late allocation. Storage space for the entire dataset should not be allocated until the + dataset is written to.
3Incremental 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 TimeAt 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: + + + + + + + + + + + + + + + + + +
ValueDescription
0On allocation. The fill value is always written to the raw data storage when the storage + space is allocated.
1Never. The fill value should never be written to the raw data storage.
2Fill 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 DefinedThis 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 field.
SizeThis 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 ValueThe 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.
+ + + + + + + + + + + + + + + + + + + + + +
Layout: Fill Value Message - Versions 3
bytebytebytebyte
VersionFlagsFill Value Write TimeThis space inserted only to align table nicely
Size (optional)

Fill Value (optional, variable size)

+ + + + + + + + + + + + + + + + + + + + + + + +
Fields: Fill Value Message - Versions 3
Field NameDescription
VersionThe version number information is used for changes in the format of the fill value message and + is described here: + + + + + + + + + + + + + + + + + + + + + +
VersionDescription
0Never used
1Initial version of this message.
2In this version, the Size and Fill Value fields are only present if the Fill Value Defined + field is set to 1.
3This version packs the other fields in the message more efficiently than version 2.
+
FlagsWhen the storage space for the dataset’s raw data will be allocated. The allowed values are: + + + + + + + + + + + + + + + + + + + + + + + + + +
BitsDescription
0-1Space Allocation Time, with the same values as versions 1 and 2 of the message.
2-3Fill Value Write Time, with the same values as versions 1 and 2 of the message.
4Fill Value Undefined, indicating that the fill value has been marked as “undefined” + for this dataset. Bits 4 and 5 cannot both be set.
5Fill Value Defined, with the same values as versions 1 and 2 of the message. Bits 4 and 5 + cannot both be set.
6-7Reserved (zero).
SizeThis 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 ValueThe 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.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_link IV.A.2.g. The Link Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Link
Header Message Type: 0x0006
Length: Varies
Status: Optional; may be repeated.
Description:This message encodes the information for a link in a group’s object header, when the group is + storing its links “compactly”, or in the group’s fractal heap, when the group is + storing its links “densely”.
+ A group is storing its links compactly when the fractal heap address in the + @ref subsubsec_fmt3_dataobject_hdr_msg_linkinfo is set to the + @ref FMT3UndefinedAddress "undefined address" value.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Link Message
bytebytebytebyte
VersionFlagsLink type (optional)This space inserted only to align table nicely

Creation Order (8 bytes, optional)

Link Name Character Set (optional)Length of Link Name (variable size)This space inserted only to align table nicely
Link Name (variable size)

Link Information (variable size)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Link Message
Field NameDescription
VersionThe version number for this message. This document describes version 1.
FlagsThis field contains information about the link and controls the presence of other fields below. + + + + + + + + + + + + + + + + + + + + + + + + + +
BitsDescription
0-1Determines the size of the Length of Link Name field. + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0The size of the Length of Link Name field is 1 byte.
1The size of the Length of Link Name field is 2 bytes.
2The size of the Length of Link Name field is 4 bytes.
3The size of the Length of Link Name field is 8 bytes.
2Creation 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.
3Link 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.
4Link 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-7Reserved (zero).
Link typeThis is the link class type and can be one of the following values: + + + + + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0A hard link (should never be stored in the file)
1A soft link.
2-63Reserved for future HDF5 internal use.
64An external link.
65-255Reserved, but available for user-defined link types.
+ This field is present if bit 3 of Flags is set.
Creation OrderThis 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 SetThis is the character set for encoding the link’s name: + + + + + + + + + + + + + +
ValueDescription
0ASCII character set encoding (this should never be stored in the file)
1UTF-8 character set encoding
+ This field is present if bit 4 of Flags is set.
Length of link nameThis is the length of the link’s name. The size of this field depends on bits 0 and 1 of Flags.
Link nameThis is the name of the link, non-NULL terminated.
Link informationThe format of this field depends on the link type.
+ For hard links, the field is formatted as follows: + + + + + +
@ref FMT3SizeOfOffsetsV0 "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.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_external IV.A.2.h. The Data Storage - External Data Files Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: External Data Files
Header Message Type: 0x0007
Length: Varies
Status: Optional; may not be repeated.
Description:The external data storage message indicates that the data for an object is stored outside the HDF5 + file. The filename of the object is stored as a Universal Resource Location (URL) of the actual + filename containing the data. An external file list record also contains the byte offset of the + start of the data within the file and the amount of space reserved in the file for that data.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + +
Layout: External File List Message
bytebytebytebyte
VersionReserved (zero)
Allocated SlotsUsed Slots

Heap AddressO


Slot Definitions...

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: External File List Message
Field NameDescription
VersionThe version number information is used for changes in the format of External Data Storage Message + and is described here: + + + + + + + + + + + + + +
VersionDescription
0Never used.
1The current version used by the library.
Allocated SlotsThe 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 SlotsThe number of initial slots which contain valid information.
Heap AddressThis is the address of a local name heap which contains the names for the external files. (The local + heap information can be found in @ref subsec_fmt3_infra_localheap in this document). The name at offset + zero in the heap is always the empty string.
Slot DefinitionsThe slot definitions are stored in order according to the array addresses they represent.
+ + + + + + + + + + + + + + + + + + +
Layout: External File List Slot
bytebytebytebyte

Name Offset in Local HeapL


File Offset in External Data FileL


Data Size in External FileL

+\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + +
Fields: External File List Slot
Field NameDescription
Name Offset in Local HeapThe 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 FileThis 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 FileThis 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 zeros past the end of the file without failing.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_layout IV.A.2.i. The Data Layout Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Data Storage - Layout
Header Message Type: 0x0008
Length: Varies
Status: Required for datasets; may not be repeated.
Description:The Data Layout message describes how the elements of a multi-dimensional array + are stored in the HDF5 file. Four types of data layout are supported: +
    +
  1. Contiguous: The array is stored in one contiguous area of the file. This layout requires that the + size of the array be constant: data manipulations such as chunking, compression, checksums or encryption + are not permitted. The message stores the total storage size of the array. The offset of an element from + the beginning of the storage area is computed as in a C array.
    2. +
  2. Chunked: The array domain is regularly decomposed into chunks, and each chunk is allocated and stored + separately. This layout supports arbitrary element traversals, compression, encryption, and checksums + (these features are described in other messages). The message stores the size of a chunk instead of the + size of the entire array; the size of the entire array can be calculated by traversing the B-tree that + stores the chunk addresses.
    3. +
  3. Compact: The array is stored in one contiguous block, as part of this object header messagei.
    4. +
  4. Virtual: This is only supported for version 4 of the Data Layout message. The message stores information + that is used to locate the global heap collection containing the Virtual Dataset (VDS) mapping information. + The mapping associates the VDS to the source dataset elements that are stored across a collection + of HDF5 files.
    5. +
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Data Layout Message (Versions 1 and 2)
bytebytebytebyte
VersionDimensionalityLayout ClassReserved (zero)
Reserved (zero)

Data AddressO (optional)

Dimension 0 Size
Dimension 1 Size
...
Dataset Element Size (optional)
Compact Data Size (optional)

Compact Data...(variable size, optional)

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Data Layout Message (Versions 1 and 2)
Field NameDescription
VersionThe version number information is used for changes in the format of the data layout message and + is described here: + + + + + + + + + + + + + + + + + +
VersionDescription
0Never used.
1Used by version 1.4 and before of the library to encode layout information. Data space is + always allocated when the data set is created.
2Used by version 1.6.x of the library to encode layout information. Data space is allocated + only when it is necessary.
DimensionalityAn array has a fixed dimensionality. This field specifies the number of dimension size fields later + in the message. The value stored for chunked storage is 1 greater than the number of dimensions in + the dataset’s dataspace. For example, 2 is stored for a 1 dimensional dataset.
Layout ClassThe layout class specifies the type of storage for the data and how the other fields of the layout + message are to be interpreted. + + + + + + + + + + + + + + + + + +
ValueDescription
0Compact Storage
1Contiguous Storage
2Chunked Storage
Data AddressFor contiguous storage, this is the address of the raw data in the file. For chunked storage this is + the address of the @ref subsubsec_fmt3_infra_btrees_v1 that is used to look up the addresses of the + chunks. This field is not present for compact storage. If the version for this message is greater than 1, + the address may have the @ref FMT3UndefinedAddress "undefined address" value, to indicate that storage + has not yet been allocated for this array.
Dimension \#n SizeFor contiguous and compact storage the dimensions define the entire size of the array while for chunked storage + they define the size of a single chunk. In all cases, they are in units of array elements (not bytes). The + first dimension stored in the list of dimensions is the slowest changing dimension and the last dimension + stored is the fastest changing dimension.
Dataset Element SizeThe size of a dataset element, in bytes. This field is only present for chunked storage.
Compact Data SizeThis field is only present for compact data storage. It contains the size of the raw data for the + dataset array, in bytes.
Compact DataThis field is only present for compact data storage. It contains the raw data for the dataset + array.
+ +Version 3 of this message re-structured the format into specific properties that are required for each layout class. + + + + + + + + + + + + + + + + +
Layout: Data Layout Message (Version 3)
bytebytebytebyte
VersionLayout ClassThis space inserted only to align table nicely

Properties (variable size)

+ + + + + + + + + + + + + + + + + + + +
Fields: Data Layout Message (Version 3)
Field NameDescription
VersionThe version number information is used for changes in the format of layout message and is + described here: + + + + + + + + + +
VersionDescription
3Used by the version 1.6.3 and later of the library to store properties for each layout class.
Layout ClassThe layout class specifies how the other fields of the layout message are to be interpreted. + + + + + + + + + + + + + + + + + +
ValueDescription
0Compact Storage
1Contiguous Storage
2Chunked Storage
PropertiesThis variable-sized field encodes information specific to each layout class and is described below. If + there is no property information specified for a layout class, the size of this field is zero bytes.
+ +\anchor FMT3CompactStorage

Class-specific information for compact layout (Class 0):


+(Note: The dimensionality information is in the Dataspace message) + + + + + + + + + + + + + + + +
Layout: Compact Storage Property Description
bytebytebytebyte
SizeThis space inserted only to align table nicely

Raw Data...(variable size)

+ + + + + + + + + + + + + + + +
Fields: Compact Storage Property Description
Field NameDescription
SizeThis field contains the size of the raw data for the dataset array, in bytes.
Raw DataThis field contains the raw data for the dataset array.
+ +\anchor FMT3ContiguousStorage

Class-specific information for contiguous storage (layout class 1):


+(Note: The dimensionality information is in the Dataspace message) + + + + + + + + + + + + + + + +
Layout: Contiguous Storage Property Description
bytebytebytebyte

AddressO


SizeL

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + +
Fields: Contiguous Storage Property Description
Field NameDescription
AddressThis is the address of the raw data in the file. The address may have the + @ref FMT3UndefinedAddress "undefined address" value, to indicate that storage has not + yet been allocated for this array.
SizeThis field contains the size allocated to store the raw data, in bytes.
+ +Class-specific information for chunked storage (layout class 2): + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Chunked Storage Property Description
bytebytebytebyte
DimensionalityThis space inserted only to align table nicely

AddressO

Dimension 0 Size
Dimension 1 Size
...
Dimension \#n Size
Dataset Element Size
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Chunked Storage Property Description
Field NameDescription
Dimensionality>A chunk has a fixed dimensionality. This field specifies the number of dimension size fields + later in the message.
AddressThis is the address of the @ref subsubsec_fmt3_infra_btrees_v1 that is used to look up the + addresses of the chunks that actually store portions of the array data. The address may have the + @ref FMT3UndefinedAddress "undefined address" value, to indicate + that storage has not yet been allocated for this array.
Dimension \#n SizeThese values define the dimension size of a single chunk, in units of array elements (not bytes). + The first dimension stored in the list of dimensions is the slowest changing dimension and the + last dimension stored is the fastest changing dimension.
Dataset Element SizeThe size of a dataset element, in bytes.
+ +\anchor FMT3DataLayoutV4

Version 4 of this message is similar to version 3 but has additional +information for the virtual layout class as well as indexing information for the chunked layout class.

+ + + + + + + + + + + + + + + + +
Layout: Data Layout Message (Version 4)
bytebytebytebyte
VersionLayout ClassThis space inserted only to align table nicely

Properties (variable size)

+ + + + + + + + + + + + + + + + + + + +
Fields: Data Layout Message (Version 4)
Field NameDescription
VersionThe value for this field is 4 and is used by version 1.10.0 and later of the library to + store properties for each layout class and indexing information for the chunked layout.
Layout ClassThe layout class specifies specifies the type of storage for the data and how the other fields + of the layout message are to be interpreted. + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0Compact Storage
1Contiguous Storage
2Chunked Storage
3Virtual Storage
PropertiesThis variable-sized field encodes information specific to each layout class as follows: + + + + + + + + + + + + + + + + + + + + + +
Layout ClassDescription
Compact StorageSee @ref FMT3CompactStorage "Compact Storage Property Description" for the version 3 + Data Layout message.
Contiguous StorageSee @ref FMT3ContiguousStorage "Contiguous Storage Property Description" for the version 3 + Data Layout message.
Chunked StorageSee @ref FMT3ChunkedStorage "Chunked Storage Property Description" below.
Virtual StorageSee @ref FMT3VirtualStorage "Virtual Storage Property Description" below.
+ +\anchor FMT3ChunkedStorage

Class-specific information for chunked storage (layout class 2):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Chunked Storage Property Description
bytebytebytebyte
FlagsDimensionalityDimension Size Encoded LengthThis space inserted only to align table nicely

Dimension 0 Size (variable size)


Dimension 1 Size (variable size)


...


Dimension \#n Size (variable size)

Chunk Indexing TypeThis space inserted only to align table nicely

Indexing Type Information (variable size)


AddressO

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Chunked Storage Property Description
Field NameDescription
FlagsThis is the chunked layout feature flag: + + + + + + + + + + + + + +
ValueDescription
DONT_FILTER_PARTIAL_BOUND_CHUNKS (bit 0)Do not apply filter to a partial edge chunk.
SINGLE_INDEX_WITH_FILTER (bit 1)A filtered chunk for Single Chunk indexing.
DimensionalityA chunk has fixed dimension. This field specifies the number of Dimension Size fields + later in the message.
Dimension Size Encoded LengthThis is the size in bytes used to encode Dimension Size.
Dimension \#n SizeThese values define the dimension size of a single chunk, in units of array elements (not bytes). + The first dimension stored in the list of dimensions is the slowest changing dimension and the + last dimension stored is the fastest changing dimension.
Chunk Indexing TypeThere are five indexing types used to look up addresses of the chunks. For more information on each + type, see @ref sec_fmt3_appendixc
+ + + + + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
1@ref subsec_fmt3_appendixc_chunk indexing type.
2@ref subsec_fmt3_appendixc_implicit indexing type.
3@ref subsec_fmt3_appendixc_fixedarr indexing type.
4@ref subsec_fmt3_appendixc_extarr indexing type.
5@ref subsec_fmt3_appendixc_appv2btree indexing type.
Indexing Type InformationThis variable-sized field encodes information specific to an indexing type. More information on + what is encoded with each type can be found below this table. +
    +
  • See @ref FMT3IndexInfoSingle "Single Chunk" below.
    • +
  • See @ref FMT3IndexInfoImplicit "Implicit" below.
    • +
  • See @ref FMT3IndexInfoFixed "Fixed Array" below.
    • +
  • See @ref FMT3IndexInfoExtensible "Extensible Array" below.
    • +
  • See @ref FMT3IndexInfoV2Btrees "Version 2 B-tree" below.
    • +
AddressThis is the address specific to an indexing type. The address may be undefined if the chunk or + index storage is not allocated yet.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
Single Chunk indexAddress of the single chunk.
Implicit indexAddress of the array of dataset chunks.
Fixed Array indexAddress of the index.
Extensible Array indexAddress of the index.
Version 2 B-tree indexAddress of the index.
+ +
    +
  1. \anchor FMT3IndexInfoSingle

    Index-specific information for Single Chunk:

    +The following information exists only when the chunk is filtered. In other words, when +DONT_FILTER_PARTIAL_BOUND_CHUNKS (bit 0) is enabled in the field flags. + + + + + + + + + + + + + + +
    Layout: Single Chunk Indexing Information
    bytebytebytebyte

    Size of filtered chunkL

    Filters for chunk
    +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + +
    Fields: Single Chunk Indexing Information
    Field NameDescription
    Size of filtered chunkThis field is the size of a filtered chunk.
    Filters for chunkThis field contains filters for the chunk.
    +
    2. + +
  2. \anchor FMT3IndexInfoImplicit

    Index-specific information for Implicit:

    + + + + + + + + + + + +
    Layout: Implicit Indexing Information
    bytebytebytebyte
    No specific indexing information
    +
    3. + +
  3. \anchor FMT3IndexInfoFixed

    Index-specific information for Fixed Array:

    + + + + + + + + + + + + +
    Layout: Fixed Array Indexing Information
    bytebytebytebyte
    Page BitsThis space inserted only to align table nicely
    + + + + + + + + + + +
    Fields: Fixed Array Indexing Information
    Field NameDescription
    Page BitsThis field contains the number of bits needed to store the maximum number of elements in a + data block page.
    +
    4. + +
  4. \anchor FMT3IndexInfoExtensible

    Index-specific information for Extensible Array:

    + + + + + + + + + + + + + + + + + +
    Layout: Extensible Array Indexing Information
    bytebytebytebyte
    Max BitsIndex ElementsMin PointersMin Elements
    Page BitsThis space inserted only to align table nicely
    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Fields: Extensible Array Indexing Information
    Field NameDescription
    Max BitsThis field contains the number of bits needed to store the maximum number of elements + in the array.
    Index ElementsThis field contains the number of elements to store in the index block.
    Min PointersThis field contains the minimum number of data block pointers for a superblock.
    Min ElementsThis field contains the minimum number of elements per data block.
    Page BitsThis field contains the number of bits needed to store the maximum number of elements in + a data block page.
    +
    5. + +
  5. \anchor FMT3IndexInfoV2Btrees

    Index-specific information for Version 2 B-tree:

    + + + + + + + + + + + + + + + + +
    Layout: Version 2 B-tree Indexing Information
    bytebytebytebyte
    Node Size
    Split PercentMerge PercentThis space inserted only to align table nicely
    + + + + + + + + + + + + + + + + + + +
    Fields: Version 2 B-tree Indexing Information
    Field NameDescription
    Node SizeThis field is the size in bytes of a B-tree node.
    Split PercentThis field is the percentage full of a B-tree node at which to split the node.
    Merge PercentThis field is the percentage full of a B-tree node at which to merge the node.
    +
    6. +
+ +\anchor FMT3VirtualStorage

Class-specific information for virtual storage (layout class 3):

+ + + + + + + <>byte + + + + + + + +
Layout: Virtual Storage Property Description
bytebytebyte

AddressO

Index
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + +
Fields: Virtual Storage Property Description
Field NameDescription
AddressThis is the address of the global heap collection where the VDS mapping entries are stored. + See @ref subsec_fmt3_infra_globalheapvds
IndexThis is the index of the data object within the global heap collection.
+ + +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_bogus IV.A.2.j. The Bogus Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Bogus
Header Message Type:0x0009
Length: 4 bytes
Status: For testing only; should never be stored in a valid file.
Description:This message is used for testing the HDF5 Library’s response to an “unknown” + message type and should never be encountered in a valid HDF5 file.
Format of Data: See the tables below.
+ + + + + + + + + + + + +
Layout: Bogus Message
bytebytebytebyte
Bogus Value
+ + + + + + + + + + + +
Fields: Bogus Message
Field NameDescription
Bogus ValueThis value should always be: 0xdeadbeef.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_groupinfo IV.A.2.k. The Group Info Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Group Info
Header Message Type: 0x000A
Length: Varies
Status: Optional; may not be repeated.
Description:This message stores information for the constants defining a “new style” group’s + behavior. Constant information will be stored in this message and variable information will be stored + in the @ref subsubsec_fmt3_dataobject_hdr_msg_linkinfo message.
+ Note: the “estimated entry” information below is used when determining the size of the + object header for the group when it is created.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + +
Layout: Group Info Message
bytebytebytebyte
VersionFlagsLink Phase Change: Maximum Compact Value (optional)
Link Phase Change: Minimum Dense Value (optional)Estimated Number of Entries (optional)
Estimated Link Name Length of Entries (optional)This space inserted only to align table nicely
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Group Info Message
Field NameDescription
VersionThe version number for this message. This document describes version 0.
FlagsThis is the group information flag with the following definition: + + + + + + + + + + + + + + + + + +
BitDescription
0If set, link phase change values are stored.
1If set, the estimated entry information is non-default + and is stored.
2-7Reserved
Link Phase Change: Maximum Compact ValueThe is the maximum number of links to store “compactly” (in the group’s object header).
+ This field is present if bit 0 of Flags is set.
Link Phase Change: Minimum Dense ValueThis is the minimum number of links to store “densely” (in the group’s fractal + heap). The fractal heap’s address is located in the @ref subsubsec_fmt3_dataobject_hdr_msg_linkinfo + message.
+ This field is present if bit 0 of Flags is set.
Estimated Number of EntriesThis is the estimated number of entries in groups. If this field is not present, the default value of + 4 will be used for the estimated number of group entries.
+ This field is present if bit 1 of Flags is set.
Estimated Link Name Length of EntriesThis is the estimated length of entry name. If this field is not present, the default value of + 8 will be used for the estimated link name length of group entries.
+ This field is present if bit 1 of Flags is set.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_filter IV.A.2.l. The Data Storage - Filter Pipeline Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Data Storage - Filter Pipeline
Header Message Type: 0x000B
Length: Varies
Status: Optional; may not be repeated.
Description:This message describes the filter pipeline which should be applied to the data stream by providing filter + identification numbers, flags, a name, and client data.
+ This message may be present in the object headers of both dataset and group objects. For datasets, it + specifies the filters to apply to raw data. For groups, it specifies the filters to apply to the + group’s fractal heap. Currently, only datasets using chunked data storage use the filter pipeline + on their raw data.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + +
Layout: Filter Pipeline Message - Version 1
bytebytebytebyte
VersionNumber of FiltersReserved (zero)
Reserved (zero)

Filter Description List (variable size)

+ + + + + + + + + + + + + + + + + + + +
Fields: Filter Pipeline Message - Version 1
Field NameDescription
VersionThe version number for this message. This table describes version 1.
Number of FiltersThe total number of filters described in this message. The maximum possible number of filters in a + message is 32.
Filter Description ListA description of each filter. A filter description appears in the next table.
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Filter Description
bytebytebytebyte
Filter IdentificationName Length
FlagsNumber of Values for Client Data

Name (variable size, optional)


Client Data (variable size, optional)

Padding (variable size, optional)
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Filter Description
Field NameDescription
Filter Identification ValueThis value, often referred to as a filter identifier, is designed to be a unique identifier for + the filter. Values from zero through 32,767 are reserved for filters supported by The HDF Group + in the HDF5 library and for filters requested and supported by third parties. Filters supported + by The HDF Group are documented immediately below. Information on 3rd-party filters can be found + at The HDF Group’s + Registered Filters page.
+ 1
To request a filter identifier, + please contact The HDF Group’s Help Desk at HDF Help Desk. + You will be asked to provide the following information: +
    +
  1. Contact information for the developer requesting the new identifier
    2. +
  2. A short description of the new filter
    3. +
  3. Links to any relevant information, including licensing information
    4. +

+ Values from 32768 to 65535 are reserved for non-distributed uses (for example, internal company usage) + or for application usage when testing a feature. The HDF Group does not track or document the use of + the filters with identifiers from this range.
+ The filters currently in library version 1.8.0 are listed below: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IdentificationNameDescription
0N/AReserved
1deflateGZIP deflate compression
2shuffleData element shuffling
3fletcher32Fletcher32 checksum
4szipSZIP compression
5nbitN-bit packing
6scaleoffsetScale and offset encoded values
Name LengthEach filter has an optional null-terminated ASCII name and this field holds the length of the name + including the null termination padded with nulls to be a multiple of eight. If the filter has no name + then a value of zero is stored in this field.
FlagsThe flags indicate certain properties for a filter. The bit values defined so far are: + + + + + + + + + + + + + +
ValueDescription
0If set then the filter is an optional filter. During output, if an optional filter fails it will be + silently skipped in the pipeline.
1-15Reserved (zero)
Number of Client Data ValuesEach filter can store integer values to control how the filter operates. The number of entries + in the Client Data array is stored in this field.
NameIf the Name Length field is non-zero then it will contain the size of this field, padded + to a multiple of eight. This field contains a null-terminated, ASCII character string to serve as + a comment/name for the filter.
Client DataThis is an array of four-byte integers which will be passed to the filter function. The Client Data + Number of Values determines the number of elements in the array.
PaddingFour bytes of zeroes are added to the message at this point if the Client Data Number of Values field + contains an odd number.
+\anchor FMT3Footnote1Change 1 If you are reading an earlier version of this document, this +link may have changed. If the link does not work, use the latest version of this document on +The HDF Group’s github website, +HDF5 File Format Specification; the link there will always be correct. + + + + + + + + + + + + + + + + + +
Layout: Filter Pipeline Message - Version 2
bytebytebytebyte
VersionNumber of FiltersThis space inserted only to align table nicely

Filter Description List (variable size)

+ + + + + + + + + + + + + + + + + + + +
Fields: Filter Pipeline Message - Version 2
Field NameDescription
VersionThe version number for this message. This table describes version 2.
Number of FiltersThe total number of filters described in this message. The maximum possible number of filters in a + message is 32.
Filter Description ListA description of each filter. A filter description appears in the next table.
+ + + + + + + + + + + + + + + + + + + + + + + +
Layout: Filter Description
bytebytebytebyte
Filter IdentificationName Length (optional)
FlagsNumber Client Data Values

Name (variable size, optional)


Client Data (variable size, optional)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Filter Description
Field NameDescription
Filter Identification ValueThis value, often referred to as a filter identifier, is designed to be a unique identifier for + the filter. Values from zero through 32,767 are reserved for filters supported by The HDF Group + in the HDF5 library and for filters requested and supported by third parties. Filters supported + by The HDF Group are documented immediately below. Information on 3rd-party filters can be found + at The HDF Group’s + Registered Filters page.
+ 1
To request a filter identifier, + please contact The HDF Group’s Help Desk at HDF Help Desk. + You will be asked to provide the following information: +
    +
  1. Contact information for the developer requesting the new identifier
    2. +
  2. A short description of the new filter
    3. +
  3. Links to any relevant information, including licensing information
    4. +

+ Values from 32768 to 65535 are reserved for non-distributed uses (for example, internal company usage) + or for application usage when testing a feature. The HDF Group does not track or document the use of + the filters with identifiers from this range.
+ The filters currently in library version 1.8.0 are listed below: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IdentificationNameDescription
0N/AReserved
1deflateGZIP deflate compression
2shuffleData element shuffling
3fletcher32Fletcher32 checksum
4szipSZIP compression
5nbitN-bit packing
6scaleoffsetScale and offset encoded values
Name LengthEach filter has an optional null-terminated ASCII name and this field holds the length of the name + including the null termination padded with nulls to be a multiple of eight. If the filter has no name + then a value of zero is stored in this field.
+ Filters with IDs less than 256 (in other words, filters that are defined in this format documentation) + do not store the Name Length or Name fields.
FlagsThe flags indicate certain properties for a filter. The bit values defined so far are: + + + + + + + + + + + + + +
ValueDescription
0If set then the filter is an optional filter. During output, if an optional filter fails it will be + silently skipped in the pipeline.
1-15Reserved (zero)
Number of Client Data ValuesEach filter can store integer values to control how the filter operates. The number of entries + in the Client Data array is stored in this field.
NameIf the Name Length field is non-zero then it will contain the size of this field, padded + to a multiple of eight. This field contains a null-terminated, ASCII character string to serve as + a comment/name for the filter.
Client DataThis is an array of four-byte integers which will be passed to the filter function. The Client Data + Number of Values determines the number of elements in the array.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_attribute IV.A.2.m. The Attribute Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Attribute
Header Message Type: 0x000C
Length: Varies
Status: Optional; may be repeated.
Description:The Attribute message is used to store objects in the HDF5 file which are used as attributes, + or “metadata” about the current object. An attribute is a small dataset; it has a name, + a datatype, a dataspace, and raw data. Since attributes are stored in the object header, they should + be relatively small (in other words, less than 64KB). They can be associated with any type of object + which has an object header (groups, datasets, or committed (named) datatypes).
+ In 1.8.x versions of the library, attributes can be larger than 64KB. See the + “ @ref subsec_attribute_special ” section of the Attributes chapter in + the @ref UG for more information.
+ Note: Attributes on an object must have unique names: the HDF5 Library currently enforces this by + causing the creation of an attribute with a duplicate name to fail. Attributes on different + objects may have the same name, however.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Attribute Message (Version 1)
bytebytebytebyte
VersionReserved (zero)Name Size
Datatype SizeDataspace Size

Name (variable size)


Datatype (variable size)


Dataspace (variable size)


Data (variable size)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Attribute Message (Version 1)
Field NameDescription
VersionThe version number information is used for changes in the format of the attribute message and is + described here: + + + + + + + + + + + + + +
VersionDescription
0Never used.
1Used by the library before version 1.6 to encode attribute message. This version does not + support shared datatypes.
Name SizeThe length of the attribute name in bytes including the null terminator. Note that the + Name field below may contain additional padding not represented by this field.
Datatype SizeThe length of the datatype description in the Datatype field below. Note that the + Datatype field may contain additional padding not represented by this field.
Dataspace SizeThe length of the dataspace description in the Dataspace field below. Note that the + Dataspace field may contain additional padding not represented by this field.
NameThe null-terminated attribute name. This field is padded with additional null characters to make it a + multiple of eight bytes.
TypeThe datatype description follows the same format as described for the datatype object header message. + This field is padded with additional zero bytes to make it a multiple of eight bytes.
SpaceThe dataspace description follows the same format as described for the dataspace object header message. + This field is padded with additional zero bytes to make it a multiple of eight bytes.
DataThe raw data for the attribute. The size is determined from the datatype and dataspace descriptions. + This field is not padded with additional bytes.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Attribute Message (Version 2)
bytebytebytebyte
VersionFlagsName Size
Datatype SizeDataspace Size

Name (variable size)


Datatype (variable size)


Dataspace (variable size)


Data (variable size)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Attribute Message (Version 2)
Field NameDescription
VersionThe version number information is used for changes in the format of the attribute message and is + described here: + + + + + + + + + +
VersionDescription
2Used by the library of version 1.6.x and after to encode attribute messages. This version + supports shared datatypes. The fields of name, datatype, and dataspace are not padded with + additional bytes of zero.
Flags>This bit field contains extra information about interpreting the attribute message: + + + + + + + + + + + + + +
BitDescription
0If set, datatype is shared.
1If set, dataspace is shared.
Name SizeThe length of the attribute name in bytes including the null terminator.
Datatype SizeThe length of the datatype description in the Datatype field below.
Dataspace SizeThe length of the dataspace description in the Dataspace field below.
NameThe null-terminated attribute name. This field is not padded with additional bytes.
DatatypeThe datatype description follows the same format as described for the datatype object + header message.
+ If the Flag field indicates this attribute’s datatype is shared, this field will + contain a “shared message” encoding instead of the datatype encoding.
+ This field is not padded with additional bytes.
DataspaceThe dataspace description follows the same format as described for the dataspace object + header message.
+ If the Flag field indicates this attribute’s dataspace is shared, this field will + contain a “shared message” encoding instead of the dataspace encoding.
+ This field is not padded with additional bytes.
DataThe raw data for the attribute. The size is determined from the datatype and dataspace + descriptions.
+ This field is not padded with additional zero bytes.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Attribute Message (Version 3)
bytebytebytebyte
VersionFlagsName Size
Datatype SizeDataspace Size
Name Character Set EncodingThis space inserted only to align table nicely

Name (variable size)


Datatype (variable size)


Dataspace (variable size)


Data (variable size)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Attribute Message (Version 3)
Field NameDescription
VersionThe version number information is used for changes in the format of the attribute message and is + described here: + + + + + + + + + +
VersionDescription
2Used by the library of version 1.8.x and after to encode attribute messages. This version + supports attributes with non-ASCII names.
Flags>This bit field contains extra information about interpreting the attribute message: + + + + + + + + + + + + + +
BitDescription
0If set, datatype is shared.
1If set, dataspace is shared.
Name SizeThe length of the attribute name in bytes including the null terminator.
Datatype SizeThe length of the datatype description in the Datatype field below.
Dataspace SizeThe length of the dataspace description in the Dataspace field below.
Name Character Set EncodingThe character set encoding for the attribute’s name: + + + + + + + + + + + + + +
ValueDescription
0ASCII character set encoding
1UTF-8 character set encoding
NameThe null-terminated attribute name. This field is not padded with additional bytes.
DatatypeThe datatype description follows the same format as described for the datatype object + header message.
+ If the Flag field indicates this attribute’s datatype is shared, this field will + contain a “shared message” encoding instead of the datatype encoding.
+ This field is not padded with additional bytes.
DataspaceThe dataspace description follows the same format as described for the dataspace object + header message.
+ If the Flag field indicates this attribute’s dataspace is shared, this field will + contain a “shared message” encoding instead of the dataspace encoding.
+ This field is not padded with additional bytes.
DataThe raw data for the attribute. The size is determined from the datatype and dataspace + descriptions.
+ This field is not padded with additional zero bytes.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_comment IV.A.2.n. The Object Comment Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Object Comment
Header Message Type: 0x000D
Length: Varies
Status: Optional; may not be repeated.
Description:The object comment is designed to be a short description of an object. An object comment is a sequence + of non-zero (\0) ASCII characters with no other formatting included by the library.
Format of Data: See the tables below.
+ + + + + + + + + + + + +
Layout: Object Comment Message
bytebytebytebyte

Comment (variable size)

+
+ + + + + + + + + + + +
Fields: Object Comment Message
Field NameDescription
NameA null terminated ASCII character string.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_omodified IV.A.2.o. The Object Modification Time (Old) Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Object Modification Time (Old)
Header Message Type: 0x000E
Length: Fixed
Status: Optional; may not be repeated.
Description:The object modification date and time is a timestamp which indicates (using ISO-8601 date and + time format) the last modification of an object. The time is updated when any object header + message changes according to the system clock where the change was posted. All fields of this + message should be interpreted as coordinated universal time (UTC).
+ This modification time message is deprecated in favor of the “new” + @ref subsubsec_fmt3_dataobject_hdr_msg_mod message and is no longer written to the file in + versions of the HDF5 Library after the 1.6.0 version.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Modification Time Message (Old)
bytebytebytebyte
Year
MonthDay of Month
HourMinute
SecondReserved
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Modification Time Message (Old)
Field NameDescription
YearThe four-digit year as an ASCII string. For example, 1998.
MonthThe month number as a two digit ASCII string where January is 01 and December is + 12.
Day of MonthThe day number within the month as a two digit ASCII string. The first day of the month is + 01.
HourThe hour of the day as a two digit ASCII string where midnight is 00 and 11:00pm + is 23.
MinuteThe minute of the hour as a two digit ASCII string where the first minute of the hour is + 00 and the last is 59.
SecondThe second of the minute as a two digit ASCII string where the first second of the minute is + 00 and the last is 59.
ReservedThis field is reserved and should always be zero.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_shared IV.A.2.p. The Shared Message Table Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Shared Message Table
Header Message Type: 0x000F
Length: Fixed
Status: Optional; may not be repeated.
Description:This message is used to locate the table of shared object header message (SOHM) indexes. Each + index consists of information to find the shared messages from either the heap or object header. + This message is only found in the superblock extension.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + +
Layout: Shared Message Table Message
bytebytebytebyte
VersionThis space inserted only to align table nicely

Shared Object Header Message Table AddressO

Number of IndicesThis space inserted only to align table nicely
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + +
Fields: Shared Message Table Message
Field NameDescription
VersionThe version number for this message. This document describes version 0.
Shared Object Header Message Table AddressThis field is the address of the master table for shared object header message indexes.
Number of IndicesThis field is the number of indices in the master table.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_continuation IV.A.2.q. The Object Header Continuation Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Object Header Continuation
Header Message Type: 0x0010
Length: Fixed
Status: Optional; may be repeated.
Description:The object header continuation is the location in the file of a block containing more header messages + for the current data object. This can be used when header blocks become too large or are likely to + change over time.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + +
Layout: Object Header Continuation Message
bytebytebytebyte

OffsetO


LengthL

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + +
Fields: Object Header Continuation Message
Field NameDescription
OffsetThis value is the address in the file where the header continuation block is located.
LengthThis value is the length in bytes of the header continuation block in the file.
+ +The format of the header continuation block that this message points to depends on the version of the +object header that the message is contained within. + +Continuation blocks for version 1 object headers have no special formatting information; they are +merely a list of object header message info sequences (type, size, flags, reserved bytes and data for +each message sequence). See the description of @ref subsubsec_fmt3_dataobject_hdr_prefix_one. + +Continuation blocks for version 2 object headers do have special formatting information as +described here (see also the description of @ref subsubsec_fmt3_dataobject_hdr_prefix_two): + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Version 2 Object Header Continuation Block
bytebytebytebyte
Signature
Header Message Type \#1Size of Header Message Data \#1Header Message \#1 Flags
Header Message \#1 Creation Order (optional)This space inserted only to align table nicely

Header Message Data \#1

.
.
.
Header Message Type \#nSize of Header Message Data \#nHeader Message \#n Flags
Header Message \#n Creation Order (optional)This space inserted only to align table nicely

Header Message Data \#n

Gap (optional, variable size)
Checksum
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 2 Object Header Continuation Block
Field NameDescription
SignatureThe ASCII character string “OCHK” is used to indicate the + beginning of an object header continuation block. This gives file consistency checking + utilities a better chance of reconstructing a damaged file.
Header Message \#n TypeSame format as version 1 of the object header, described above.
Size of Header Message \#n DataSame format as version 1 of the object header, described above.
Header Message \#n FlagsSame format as version 1 of the object header, described above.
Header Message \#n Creation OrderThis 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 DataSame format as version 1 of the object header, described above.
GapA 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.
ChecksumThis is the checksum for the object header chunk.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_stmgroup IV.A.2.r. The Symbol Table Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Symbol Table Message
Header Message Type: 0x0011
Length: Fixed
Status: Required for “old style” groups; may not be repeated.
Description:Each “old style” group has a v1 B-tree and a local heap for storing symbol table entries, + which are located with this message.
Format of data: See the tables below.
+ + + + + + + + + + + + + + + +
Layout: Symbol Table Message
bytebytebytebyte

v1 B-tree AddressO


Local Heap AddressO

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + +
Fields: Symbol Table Message
Field NameDescription
v1 B-tree AddressThis value is the address of the v1 B-tree containing the symbol table entries for the group.
Local Heap AddressThis value is the address of the local heap containing the link names for the symbol table + entries for the group.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_mod IV.A.2.s. The Object Modification Time Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Object Modification Time
Header Message Type: 0x0012
Length: Fixed
Status: Optional; may not be repeated.
Description:The object modification time is a timestamp which indicates the time of the last modification of + an object. The time is updated when any object header message changes according to the system clock + where the change was posted.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + +
Layout: Modification Time Message
bytebytebytebyte
VersionReserved (zero)
Seconds After UNIX Epoch
+ + + + + + + + + + + + + + + +
Fields: Modification Time Message
Field NameDescription
VersionThe version number is used for changes in the format of Object Modification Time and is described + here: + + + + + + + + + + + + + +
VersionDescription
0Never used.
1Used by Version 1.6.1 and after of the library to encode time. In this version, the time is + the seconds after Epoch.
Seconds After UNIX EpochA 32-bit unsigned integer value that stores the number of seconds since 0 hours, 0 minutes, + 0 seconds, January 1, 1970, Coordinated Universal Time.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_btreek IV.A.2.t. The B-tree ‘K’ Values Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: B-tree ‘K’ Values
Header Message Type: 0x0013
Length: Fixed
Status: Optional; may not be repeated.
Description:This message retrieves non-default ‘K’ values for internal and leaf nodes of a group + or indexed storage v1 B-trees. This message is only found in the superblock extension.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + +
Layout: B-tree ‘K’ Values Message
bytebytebytebyte
VersionIndexed Storage Internal Node KThis space inserted only to align table nicely
Group Internal Node KGroup Leaf Node K
+ + + + + + + + + + + + + + + + + + + + + + + +
Fields: B-tree ‘K’ Values Message
Field NameDescription
VersionThe version number for this message. This document describes version 0.
Indexed Storage Internal Node KThis is the node ‘K’ value for each internal node of an indexed storage v1 B-tree. + See the description of this field in version 0 and 1 of the superblock as well the section on + v1 B-trees.
Group Internal Node KThis is the node ‘K’ value for each internal node of a group v1 B-tree. See the + description of this field in version 0 and 1 of the superblock as well as the section + on v1 B-trees.
Group Leaf Node KThis is the node ‘K’ value for each leaf node of a group v1 B-tree. See the + description of this field in version 0 and 1 of the superblock as well as the section on v1 + B-trees.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_drvinfo IV.A.2.u. The Driver Info Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Driver Info
Header Message Type: 0x0014
Length: Varies
Status: Optional; may not be repeated.
Description:This message contains information needed by the file driver to reopen a file. This message is + only found in the superblock extension: see the @ref subsec_fmt3_boot_supext section + for more information. For more information on the fields in the driver info message, see the + @ref subsec_fmt3_boot_driver section; those who use the multi and family file drivers will find + this section particularly helpful.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + +
Layout: Driver Info Message
bytebytebytebyte
VersionThis space inserted only to align table nicely

Driver Identification
Driver Information SizeThis space inserted only to align table nicely


Driver Information (variable size)


+ + + + + + + + + + + + + + + + + + + + + + + +
Fields: Driver Info Message
Field NameDescription
VersionThe version number for this message. This document describes version 0.
Driver IdentificationThis is an eight-byte ASCII string without null termination which identifies the driver.
Driver Information SizeThe size in bytes of the Driver Information field of this message.
Driver InformationDriver information is stored in a format defined by the file driver.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_attrinfo IV.A.2.v. The Attribute Info Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Attribute Info
Header Message Type: 0x0015
Length: Varies
Status: Optional; may not be repeated.
Description:This message stores information about the attributes on an object, such as the maximum creation + index for the attributes created and the location of the attribute storage when the attributes + are stored “densely”.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + +
Layout: Attribute Info Message
bytebytebytebyte
VersionFlagsMaximum Creation Index (optional)

Fractal Heap AddressO


Attribute Name v2 B-tree AddressO


Attribute Creation Order v2 B-tree AddressO (optional)

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Attribute Info Message
Field NameDescription
VersionThe version number for this message. This document + describes version 0.
FlagsThis is the attribute index information flag with the following definition: + + + + + + + + + + + + + + + + + +
BitDescription
0If set, creation order for attributes is tracked.
1If set, creation order for attributes is indexed.
2-7Reserved
Maximum Creation IndexThe is the maximum creation order index value for the attributes on the object.
+ This field is present if bit 0 of Flags is set.
Fractal Heap AddressThis is the address of the fractal heap to store dense attributes. Each attribute stored in the + fractal heap is described by the @ref subsubsec_fmt3_dataobject_hdr_msg_attribute.
Attribute Name v2 B-tree AddressThis is the address of the version 2 B-tree to index the names of densely stored attributes.
Attribute Creation Order v2 B-tree AddressThis is the address of the version 2 B-tree to index the creation order of densely stored + attributes.
+ This field is present if bit 1 of Flags is set.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_refcount IV.A.2.w. The Object Reference Count Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: Object Reference Count
Header Message Type: 0x0016
Length: Fixed
Status: Optional; may not be repeated.
Description:This message stores the number of hard links (in groups or objects) pointing to an object: in + other words, its reference count.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + +
Layout: Object Reference Count
bytebytebytebyte
VersionThis space inserted only to align table nicely
Reference count
+ + + + + + + + + + + + + + + +
Fields: Object Reference Count
Field NameDescription
VersionThe version number for this message. This document describes version 0.
Reference CountThe unsigned 32-bit integer is the reference count for the object. This message is only present + in “version 2” (or later) object headers, and if not present in those object header versions, + the reference count for the object is assumed to be 1.
+ +\subsubsection subsubsec_fmt3_dataobject_hdr_msg_fsinfo IV.A.2.x. The File Space Info Message + + + + + + + + + + + + + + + + + + + + +
Header Message Name: File Space Info
Header Message Type: 0x0017
Length: Fixed
Status: Optional; may not be repeated.
Description:This message stores the file space management information that the library uses in handling file + space requests for the file. Version 0 of the message is used for release 1.10.0 only. Version 1 + of the message is used for release 1.10.1+. There is no File Space Info message before release + 1.10 as the library does not track file space across multiple file opens.
+ Note that version 0 is deprecated starting in release 1.10.1. That means when the 1.10.1+ library + opens an HDF5 file with a version 0 message, the library will decode and map the message to + version 1. On file close, it will encode the message as a version 1 message.
+ The library uses the following three mechanisms to manage file space in an HDF5 file: +
    +
  • Free-space managers
    + They track free-space sections of various sizes in the file that are not currently + allocated. Each free-space manager corresponds to a file space type. There are two main + groups of file space types: metadata and raw data. Metadata is further divided into five + types: superblock, B-tree, global heap, local heap, and object header. See the description + of @ref subsec_fmt3_infra_freespaceindex as well the description of file space allocation + types in @ref sec_fmt3_appendixb.
    • +
  • Aggregators
    + The library manages two aggregators, one for metadata and one for raw data. Aggregator is + a contiguous block of free-space in the file. The size of each aggregator is tunable via + public routines #H5Pset_meta_block_size and #H5Pset_small_data_block_size respectively.
    • +
  • Virtual file drivers
    + The library's virtual file driver interface dispatches requests for additional space to the + allocation routine of the file driver associated with the file. For example, if the sec2 + file driver is being used, its allocation routine will increase the size of the file to + service the requests.
    • +
+ For release 1.10.0, the library derives the following four file space strategies based on the mechanisms: +
    +
  • #H5F_FILE_SPACE_ALL +
      +
    • Mechanisms used: free-space managers, aggregators, and virtual file drivers
      • +
    • Does not persist free-space across file opens
      • +
    • This strategy is the library default
      • +
    +
    • +
  • #H5F_FILE_SPACE_ALL_PERSIST
    • +
      +
    • Mechanisms used: free-space managers, aggregators, and virtual file drivers
      • +
    • Persist free-space across file opens
      • +
    +
  • #H5F_FILE_SPACE_AGGR_VFD
    • +
      +
    • Mechanisms used: aggregators and virtual file drivers
      • +
    • Does not persist free-space across file opens
      • +
    +
  • #H5F_FILE_SPACE_VFD
    • +
      +
    • Mechanisms used: virtual file drivers
      • +
    • Does not persist free-space across file opens
      • +
    +
+ For release 1.10.1+, the free-space manager mechanism is modified to handle paged aggregation + which aggregates small metadata and raw data allocations into constant-sized well-aligned pages + to allow efficient I/O accesses. With the support of this feature, the library derives the + following four file space strategies: +
    +
  • #H5F_FSPACE_STRATEGY_FSM_AGGR
    • +
      +
    • Mechanisms used: free-space managers, aggregators, and virtual file drivers
      • +
    • This strategy is the library default
      • +
    +
  • #H5F_FSPACE_STRATEGY_PAGE
    • +
      +
    • Mechanisms used: free-space managers with embedded paged aggregation and virtual file drivers
      • +
    +
  • #H5F_FSPACE_STRATEGY_AGGR
    • +
      +
    • Mechanisms used: aggregators and virtual file drivers
      • +
    +
  • #H5F_FSPACE_STRATEGY_NONE
    • +
      +
    • Mechanisms used: virtual file drivers
      • +
    +
+ The default is not persisting free-space across file opens for the above four strategies. User can use + the public routine #H5Pset_file_space_strategy to request persisting free-space.
Format of Data: See the tables below.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: File Space Info
bytebytebytebyte
VersionStrategyThresholdL

Free-space manager addressO for #H5FD_MEM_SUPER


Free-space manager addressO for #H5FD_MEM_BTREE


Free-space manager addressO for #H5FD_MEM_DRAW


Free-space manager addressO for #H5FD_MEM_GHEAP


Free-space manager addressO for #H5FD_MEM_LHEAP


Free-space manager addressO for #H5FD_MEM_OHDR

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + +
Fields: File Space Info
Field NameDescription
VersionThis is the version 0 of this message.
StrategyThis is the file space strategy used to manage file space. There are four types: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
1#H5F_FILE_SPACE_ALL_PERSIST
2#H5F_FILE_SPACE_ALL
3#H5F_FILE_SPACE_AGGR_VFD
4#H5F_FILE_SPACE_VFD
ThresholdThis is the smallest free-space section size that the free-space manager will track.
Free-space manager addressesThese are the six free-space manager addresses for the six file space allocation types: +
    +
  • #H5FD_MEM_SUPER
    • +
  • #H5FD_MEM_BTREE
    • +
  • #H5FD_MEM_DRAW
    • +
  • #H5FD_MEM_GHEAP
    • +
  • #H5FD_MEM_LHEAP
    • +
  • #H5FD_MEM_OHDR
    • +
+ Note that these six fields exist only if the value for the field “Strategy” + is #H5F_FILE_SPACE_ALL_PERSIST.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: File Space Info - Version 1
bytebytebytebyte
VersionStrategyPersisting free-spaceThis space inserted only to align table nicely
Free-space Section ThresholdL
File Space Page Size
Page-end Metadata thresholdThis space inserted only to align table nicely
EOAO

AddressO of small-sized free-space manager for #H5FD_MEM_SUPER


AddressO of small-sized free-space manager for #H5FD_MEM_BTREE


AddressO of small-sized free-space manager for #H5FD_MEM_DRAW


AddressO of small-sized free-space manager for #H5FD_MEM_GHEAP


AddressO of small-sized free-space manager for #H5FD_MEM_LHEAP


AddressO of small-sized free-space manager for #H5FD_MEM_OHDR


AddressO of large-sized free-space manager for #H5FD_MEM_SUPER


AddressO of large-sized free-space manager for #H5FD_MEM_BTREE


AddressO of large-sized free-space manager for #H5FD_MEM_DRAW


AddressO of large-sized free-space manager for #H5FD_MEM_GHEAP


AddressO of large-sized free-space manager for #H5FD_MEM_LHEAP


AddressO of large-sized free-space manager for #H5FD_MEM_OHDR

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: File Space Info - Version 1
Field NameDescription
VersionThis is the version 1 of this message.
StrategyThis is the file space strategy used to manage file space. There are four types: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0#H5F_FSPACE_STRATEGY_FSM_AGGR
1#H5F_FSPACE_STRATEGY_PAGE
2#H5F_FSPACE_STRATEGY_AGGR
3#H5F_FSPACE_STRATEGY_NONE
Persisting free-spaceTrue or false in persisting free-space.
Free-space Section ThresholdThis is the smallest free-space section size that the free-space manager will track.
File space page sizeThis is the file space page size, which is used when the paged aggregation feature is enabled.
Page-end metadata thresholdThis is the smallest free-space section size at the end of a page that the free-space manager will + track. This is used when the paged aggregation feature is enabled.
EOAThe EOA before the allocation of free-space manager header and section info for the self-referential + free-space managers when persisting free-space.
+ Note that self-referential free-space managers are managers that involve file space allocation for + the managers' free-space header and section info.
Addresses of small-sized free-space managersThese are the addresses of the six small-sized free-space manager addresses for the six file space + allocation types: +
    +
  • #H5FD_MEM_SUPER
    • +
  • #H5FD_MEM_BTREE
    • +
  • #H5FD_MEM_DRAW
    • +
  • #H5FD_MEM_GHEAP
    • +
  • #H5FD_MEM_LHEAP
    • +
  • #H5FD_MEM_OHDR
    • +
+ Note that these six fields exist only if the value for the field + “Persisting free-space” is true.
Addresses of large-sized free-space managersThese are the addresses of the six large-sized free-space manager addresses for the six file space + allocation types: +
    +
  • #H5FD_MEM_SUPER
    • +
  • #H5FD_MEM_BTREE
    • +
  • #H5FD_MEM_DRAW
    • +
  • #H5FD_MEM_GHEAP
    • +
  • #H5FD_MEM_LHEAP
    • +
  • #H5FD_MEM_OHDR
    • +
+ Note that these six fields exist only if the value for the field + “Persisting free-space” is true.
+ +\subsection subsec_fmt3_dataobject_storage IV.B. Disk Format: Level 2B - Data Object Data Storage +The data for an object is stored separately from the header information in the file and may not actually +be located in the HDF5 file itself if the header indicates that the data is stored externally. The +information for each record in the object is stored according to the dimensionality of the object +(indicated in the dataspace header message). Multi-dimensional array data is stored in C order; in other +words, the “last” dimension changes fastest. + +Data whose elements are composed of atomic datatypes are stored in IEEE format, unless +they are specifically defined as being stored in a different machine format with the architecture-type +information from the datatype header message. This means that each architecture will need to +[potentially] byte-swap data values into the internal representation for that particular machine. + +Data with a variable-length datatype is stored in the global heap of the HDF5 file. Global heap +identifiers are stored in the data object storage. + +Data whose elements are composed of reference datatypes are stored in several different ways depending +on the particular reference type involved. Object pointers are just stored as the offset of the +object header being pointed to with the size of the pointer being the same number of bytes as offsets +in the file. + +Dataset region references are stored as a heap-ID which points to the following information within the +file-heap: an offset of the object pointed to, number-type information (same format as header message), +dimensionality information (same format as header message), sub-set start and end information (in other +words, a coordinate location for each), and field start and end names (in other words, a [pointer to the] +string indicating the first field included and a [pointer to the] string name for the last field). + +Data of a compound datatype is stored as a contiguous stream of the items in the structure, with each +item formatted according to its datatype.
+Description of datatypes for variable-length, references and compound classes can be found in +@ref subsubsec_fmt3_dataobject_hdr_msg_dtmessage.
+Information about global heap and heap ID can be found in @ref subsec_fmt3_infra_globalheap..
+For reference datatype, see also the encoding description for @ref subsec_fmt3_appendixd_encoderv and +@ref subsec_fmt3_appendixd_encodedp in Appendix D. + + +\section sec_fmt3_appendixa V. Appendix A: Definitions +Definitions of various terms used in this document are included in this section. + + + + + + + + + + + + + +
TermDefinition
Undefined Address\anchor FMT3UndefinedAddress The "undefined address" for a file is a file address with all bits + set: in other words, 0xffff...ff.
Unlimited Size\anchor FMT3UnlimitedDim The "unlimited size" for a size is a value with all bits set: in other words, + 0xffff...ff.
+ +\section sec_fmt3_appendixb VI. Appendix B: File Space Allocation Types +There are six basic types of file memory allocation as follows: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Basic Allocation TypeDescription
#H5FD_MEM_SUPERFile space allocated for Superblock.
#H5FD_MEM_BTREEFile space allocated for B-tree.
#H5FD_MEM_DRAWFile space allocated for raw data.
#H5FD_MEM_GHEAPFile space allocated for Global Heap.
#H5FD_MEM_LHEAPFile space allocated for Local Heap.
#H5FD_MEM_OHDRFile space allocated for Object Header.
+ +There are other file space allocation types that are mapped to the above six basic types +because they are similar in nature. The mapping and the corresponding description are +listed in the following two tables: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Basic Allocation TypeMapping of Allocation Types to Basic Allocation Types
#H5FD_MEM_SUPERnone
#H5FD_MEM_BTREE#H5FD_MEM_SOHM_INDEX
#H5FD_MEM_DRAW#H5FD_MEM_FHEAP_HUGE_OBJ
#H5FD_MEM_GHEAPnone
#H5FD_MEM_LHEAP#H5FD_MEM_FHEAP_DBLOCK, #H5FD_MEM_FSPACE_SINFO
#H5FD_MEM_OHDR#H5FD_MEM_FHEAP_HDR, #H5FD_MEM_FHEAP_IBLOCK, #H5FD_MEM_FSPACE_HDR, #H5FD_MEM_SOHM_TABLE
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Allocation TypeDescription
#H5FD_MEM_FHEAP_HDRFile space allocated for Fractal Heap Header.
#H5FD_MEM_FHEAP_DBLOCKFile space allocated for Fractal Heap Direct Blocks.
#H5FD_MEM_FHEAP_IBLOCKFile space allocated for Fractal Heap Indirect Blocks.
#H5FD_MEM_FHEAP_HUGE_OBJFile space allocated for huge objects in the fractal heap.
#H5FD_MEM_FSPACE_HDRFile space allocated for Free-space Manager Header.
#H5FD_MEM_FSPACE_SINFOFile space allocated for Free-space Section List of the free-space manager.
#H5FD_MEM_SOHM_TABLEFile space allocated for Shared Object Header Message Table.
#H5FD_MEM_SOHM_INDEXFile space allocated for Shared Message Record List.
+ +\section sec_fmt3_appendixc VII. Appendix C: Types of Indexes for Dataset Chunks +For an HDF5 file without the latest format enabled, the library uses the +@ref subsubsec_fmt3_infra_btrees_v1 to index dataset chunks.
+For an HDF5 file with the latest format enabled, the library uses one of the following five +indexing types depending on a chunked dataset’s dimension specification and the way it +is extended. + +\subsection subsec_fmt3_appendixc_chunk VII.A. The Single Chunk Index +The Single Chunk index can be used when the dataset fulfills the following condition: + + +The dataset has only one chunk, and the address of the single chunk is stored in the version 4 +Data Layout message. See the @ref subsec_fmt3_appendixc_chunk layout and field description tables. + +\subsection subsec_fmt3_appendixc_implicit VII.B. The Implicit Index +The Implicit index can be used when the dataset fulfills the following conditions: + + +Since the dataset’s dimension sizes are known and storage space is to be allocated early, an +array of dataset chunks are allocated based on the maximum dimension sizes when the dataset is created. +The base address of the array is stored in the version 4 Data Layout message. See the +@ref subsec_fmt3_appendixc_chunk layout layout and field description tables.
+When accessing a dataset chunk with a specified offset, the address of the chunk in the array is computed +as below: +\code +base address + (size of a chunk in bytes * chunk index associated with the offset) +\endcode + +\anchor FMT3ChunkIndex A chunk index starts at 0 and increases according to the fastest changing +dimension, then the next fastest, and so on. The chunk index for a dataset chunk offset is computed as below: +
    +
  1. Calculate the scaled offset for each dimension in scaled_offset:
    + scaled_offset = chunk_offset/chunk_dims
    2. +
  2. Calculate the # of chunks for each dimension in nchunks:
    + nchunks = (curr_dims + chunk_dims - 1)/chunk_dims
    3. +
  3. Calculate the down chunks for each dimension in down_chunks:
    + + // n is the # of dimensions + for(i = (int)(n-1), acc = 1; i >= 0; i--) { + down_chunks[i] = acc; + acc *= nchunks[i]; + } +
    4. +
  4. Calculate the chunk index in chunk_index:
    + + // n is the # of dimensions + for(u = 0, chunk_index = 0; u < n; u++) + chunk_index += down_chunks[u] * scaled_offset[u]; +
    5. +
+ +For example, for a 2-dimensional dataset with curr_dims[4,5] and +chunk_dims[3,2], there will be a total of 6 chunks, with 3 chunks in the fastest +changing dimension and 2 chunks in the slowest changing dimension. See the figure below. +The chunk index for the chunk offset [3,4] is computed as below: +
    +
  1. scaled_offset[0] = 1, scaled_offset[1] = 2
    2. +
  2. nchunks[0] = 2, nchunks[1] = 3
    3. +
  3. down_chunks[0] = 3, down_chunks[1] = 1
    4. +
  4. chunk_index = 5
    5. +
+ + + + + + + + +
Figure 3: Implicit index chunk diagram
\image html FileFormatSpecChunkDiagram.jpg
+ +\subsection subsec_fmt3_appendixc_fixedarr VII.C. The Fixed Array Index +The Fixed Array index can be used when the dataset fulfills the following condition: + + +Since the maximum number of chunks is known, an array of in-file-on-disk addresses based on the +maximum number of chunks is allocated when data is written to the dataset. To access a dataset +chunk with a specified offset, the @ref FMT3ChunkIndex "chunk index" associated with the offset +is calculated. The index is mapped into the array to locate the disk address for the chunk.
+The Fixed Array (FA) index structure provides space and speed improvements in locating chunks over +index structures that handle more dynamic data accesses like a +@ref subsec_fmt3_appendixc_appv2btree index.The entry into the Fixed Array is the Fixed Array +header which contains metadata about the entries stored in the array. The header contains a +pointer to a data block which stores the array of entries that describe the dataset chunks. +For greater efficiency, the array will be divided into multiple pages if the number of entries +exceeds a threshold value. The space for the data block and possibly data block pages are allocated +as a single contiguous block of space.
+The content of the data block depends on whether paging is activated or not. When paging is not +used, elements that describe the chunks are stored in the data block. If paging is turned on, +the data block contains a bitmap indicating which pages are initialized. Then subsequent data +block pages will contain the entries that describe the chunks.
+An entry describes either a filtered or non-filtered dataset chunk. The formats for both element +types are described below.
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Fixed Array Header
bytebytebytebyte
Signature
VersionClient IDEntry SizePage Bits

Max Num EntriesL


Data Block AddressO

Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Fixed Array Header
Field NameDescription
SignatureThe ASCII character string “FAHD” + is used to indicate the beginning of a Fixed Array header. + This gives file consistency checking utilities a better + chance of reconstructing a damaged file.
VersionThis document describes version 0.
Client IDThe ID for identifying the client of the Fixed Array: + + + + + + + + + + + + + + + + + +
IDDescription
0Non-filtered dataset chunks
1Filtered dataset chunks
2+Reserved
Entry SizeThe size in bytes of an entry in the Fixed Array.
Page BitsThe number of bits needed to store the maximum number of entries in a + @ref FMT3FADataBlockPage "data block page"
Max Num EntriesThe maximum number of entries in the Fixed Array.
Data Block AddressThe address of the data block in the Fixed Array.
ChecksumThe checksum for the header.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Fixed Array Data Block
bytebytebytebyte
Signature
VersionClient IDThis space inserted only to align table nicely

Header AddressO


Page Bitmap (variable size and optional)


Elements (variable size and optional)

Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Fixed Array Data Block
Field NameDescription
SignatureThe ASCII character string “FADB” is used to indicate the + beginning of a Fixed Array data block. This gives file consistency checking utilities a + better chance of reconstructing a damaged file.
VersionThis document describes version 0.
Client IDThe ID for identifying the client of the Fixed Array: + + + + + + + + + + + + + + + + + +
IDDescription
0Non-filtered dataset chunks
1Filtered dataset chunks
2+Reserved.
Header AddressThe address of the Fixed Array header. Principally used for file integrity checking.
Page BitmapA bitmap indicating which data block pages are initialized.
+ Exists only if the data block is paged.
ElementsContains the elements stored in the data block and exists only if the data block is not paged. + There are two element types: + + + + + + + + + + + + + +
IDDescription
0@ref FMT3FaNonFilterChunk "Non-filtered dataset chunks"
1@ref FMT3FaFilterChunk "Filtered dataset chunks"
ChecksumThe checksum for the Fixed Array data block.
+ + + + + + + + + + + + + + + +
\anchor FMT3FADataBlockPage Layout: Fixed Array Data Block Page
bytebytebytebyte

Elements (variable size)

Checksum
+ + + + + + + + + + + + + + + +
Fields: Fixed Array Data Block Page
Field NameDescription
ElementsContains the elements stored in the data block page. + There are two element types: + + + + + + + + + + + + + +
IDDescription
0@ref FMT3FaNonFilterChunk "Non-filtered dataset chunks"
1@ref FMT3FaFilterChunk "Filtered dataset chunks"
ChecksumThe checksum for a Fixed Array data block page.
+ +\anchor FMT3FaNonFilterChunk + + + + + + + + + + + +
Layout: Data Block Element for Non-filtered Dataset Chunk
bytebytebytebyte

AddressO

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + +
Fields: Data Block Element for Non-filtered Dataset Chunk
Field NameDescription
AddressThe address of the dataset chunk in the file.
+ +\anchor FMT3FaFilterChunk + + + + + + + + + + + + + + + + + +
Layout: Data Block Element for Filtered Dataset Chunk
bytebytebytebyte

AddressO


Chunk Size (variable size; at most 8 bytes)

Filter Mask
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + +
Fields: Data Block Element for Filtered Dataset Chunk
Field NameDescription
AddressThe address of the dataset chunk in the file.
Chunk SizeThe size of the dataset chunk in bytes.
Filter MaskIndicates the filter to skip for the dataset chunk. Each + filter has an index number in the pipeline; if that filter is + skipped, the bit corresponding to its index is set.
+ +\section subsec_fmt3_appendixc_extarr VII.D. The Extensible Array Index +The Extensible Array index can be used when the dataset fulfills the following condition: + + +The Extensible Array (EA) is a data structure that is used as a chunk index in datasets where the +dataspace has a single unlimited dimension. In other words, one dimension is set to +H5S_UNLIMITED, and the other dimensions are any number of fixed-size dimensions. The +idea behind the extensible array is that a particular data object can be located via a lightweight +indexing structure of fixed depth for a given address space. This indexing structure requires only +a few (2-3) file operations per element lookup and gives good cache performance. Unlike the B-tree +structure, the extensible array is optimized for appends. Where a B-tree would always add at the +rightmost node under these circumstances, either creating a deep tree (version 1) or requiring +expensive rebalances to correct (version 2), the extensible array has already mapped out a pre-balanced +internal structure. This optimized internal structure is instantiated as needed when chunk +records are inserted into the structure.
+An Extensible Array consists of a header, an index block, secondary blocks, data blocks, and +(optional) data block pages. The general scheme is that the index block is used to reference a +secondary block, which is, in turn, used to reference the data block page where the chunk information +is stored. The data blocks will be paged for efficiency when their size passes a threshold value. +These pages are laid out contiguously on the disk after the data block, are initialized as needed, +and are tracked via bitmaps stored in the secondary block. The number of secondary and data +blocks/pages in a chunk index varies as they are allocated as needed and the first few are +(conceptually) stored in parent elements as an optimization. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Layout: Extensible Array Header +
bytebytebytebyte
Signature
VersionClient IDElement SizeMax Nelmts Bits
Index Blk ElmtsData Blk Min ElmtsSecondary Blk Min Data PtrsMax Data Blk Page Nelmts Bits

Num Secondary BlksL


Secondary Blk SizeL


Num Data BlksL


Data Blk SizeL


Max Index SetL


Num ElementsL


Index Block AddressO

Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. +\li Items marked with an ‘L’ in the above table are of the size specified in + “@ref FMT3SizeOfLengthsV0 "Size of Lengths"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Extensible Array Header
Field NameDescription
SignatureThe ASCII character string “EAHD” is used to indicate the beginning + of an Extensible Array header. This gives file consistency checking utilities a better chance + of reconstructing a damaged file.
VersionThis document describes version 0.
Client IDThe ID for identifying the client of the Fixed Array: + + + + + + + + + + + + + + + + + +
IDDescription
0Non-filtered dataset chunks
1Filtered dataset chunks
2+Reserved.
Element SizeThe size in bytes of an element in the Extensible Array.
Max Nelmts BitsThe number of bits needed to store the maximum number of elements in the Extensible Array.
Index Blk ElmtsThe number of elements to store in the index block.
Data Blk Min ElmtsThe minimum number of elements per data block.
Secondary Blk Min Data PtrsThe minimum number of data block pointers for a secondary block.
Max Dblk Page Nelmts BitsThe number of bits needed to store the maximum number of elements in a data block page.
Num Secondary BlksThe number of secondary blocks created.
Secondary Blk SizeThe size of the secondary blocks created.
Num Data BlksThe number of data blocks created.
Data Blk SizeThe size of the data blocks created.
Max Index SetThe maximum index set.
Num ElmtsThe number of elements realized.
Index Block AddressThe address of the index block.
ChecksumThe checksum for the header.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Extensible Array Index Block
bytebytebytebyte
Signature
VersionClient IDThis space inserted only to align table nicely

Header AddressO


Elements (variable size and optional)


Data Block Addresses (variable size and optional)


Secondary Block Addresses (variable size and optional)

Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Extensible Array Index Block
Field NameDescription
SignatureThe ASCII character string “EAIB” is used to indicate the beginning + of an Extensible Array Index Block. This gives file consistency checking utilities a better + chance of reconstructing a damaged file.
VersionThis document describes version 0.
Client IDThe client ID for identifying the user of the Extensible Array: + + + + + + + + + + + + + + + + + +
IDDescription
0Non-filtered dataset chunks
1Filtered dataset chunks
2+Reserved.
Header AddressThe address of the Extensible Array header. Principally used for file integrity checking.
ElementsContains the elements that are stored directly in the index block. An optimization to avoid unnecessary + secondary blocks.
There are two element types: + + + + + + + + + + + + + +
IDDescription
0@ref FMT3EaNonFilterChunk "Non-filtered dataset chunks"
1@ref FMT3EaFilterChunk "Filtered dataset chunks"
Data Block AddressesContains the addresses of the data blocks that are stored directly in the Index Block. An + optimization to avoid unnecessary secondary blocks.
Secondary Block AddressesContains the addresses of the secondary blocks.
ChecksumThe checksum for the Extensible Array Index Block.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Extensible Array Secondary Block
bytebytebytebyte
Signature
VersionClient IDThis space inserted only to align table nicely

Header AddressO


Block Offset (variable size)


Page Bitmap (variable size and optional)


Data Block Addresses (variable size and optional)

Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Extensible Array Secondary Block
Field NameDescription
SignatureThe ASCII character string “EASB” is used to indicate the beginning + of an Extensible Array Secondary Block. This gives file consistency checking utilities + a better chance of reconstructing a damaged file.
VersionThis document describes version 0.
Client IDThe ID for identifying the client of the Extensible Array: + + + + + + + + + + + + + + + + + +
IDDescription
0Non-filtered dataset chunks
1Filtered dataset chunks
2+Reserved.
Header AddressThe address of the Extensible Array header. Principally used for file integrity checking.
Block OffsetStores the offset of the block in the array.
Page BitmapA bitmap indicating which data block pages are initialized.
+ Exists only if the data block is paged.
Data Block AddressesContains the addresses of the data blocks referenced by this secondary block.
ChecksumThe checksum for the Extensible Array Secondary Block.
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Extensible Array Data Block
bytebytebytebyte
Signature
VersionClient IDThis space inserted only to align table nicely

Header AddressO


Block Offset (variable size)


Elements (variable size and optional)

Checksum
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Extensible Array Data Block
Field NameDescription
SignatureThe ASCII character string “EADB” is used to indicate the beginning + of an Extensible Array data block. This gives file consistency checking utilities a better + chance of reconstructing a damaged file.
VersionThis document describes version 0.
Client IDThe ID for identifying the client of the Extensible Array: + + + + + + + + + + + + + + + + + +
IDDescription
0Non-filtered dataset chunks
1Filtered dataset chunks
2+Reserved.
Header AddressThe address of the Extensible Array header. Principally used for file integrity checking.
Block OffsetThe offset of the block in the array.
ElementsContains the elements stored in the data block and exists only if the data block is not paged. +
There are two element types: + + + + + + + + + + + + + +
IDDescription
0@ref FMT3EaNonFilterChunk "Non-filtered dataset chunks"
1@ref FMT3EaFilterChunk "Filtered dataset chunks"
ChecksumThe checksum for the Extensible Array data block.
+ + + + + + + + + + + + + + + +
Layout: Extensible Array Data Block Page
bytebytebytebyte

Elements (variable size)

Checksum
+
+ + + + + + + + + + + + + + +
Fields: Extensible Array Data Block Page
Field NameDescription
ElementsContains the elements stored in the data block page.
+ There are two element types: + + + + + + + + + + + + + +
IDDescription
0@ref FMT3EaNonFilterChunk "Non-filtered dataset chunks"
1@ref FMT3EaFilterChunk "Filtered dataset chunks"
ChecksumThe checksum for an Extensible Array data block page.
+ +\anchor FMT3EaNonFilterChunk + + + + + + + + + + + +
Layout: Data Block Element for Non-filtered Dataset Chunk
bytebytebytebyte

AddressO

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + +
Fields: Data Block Element for Non-filtered Dataset Chunk
Field NameDescription
AddressThe address of the dataset chunk in the file.
+ +\anchor FMT3EaFilterChunk + + + + + + + + + + + + + + + + + +
Layout: Data Block Element for Filtered Dataset Chunk
bytebytebytebyte

AddressO


Chunk Size (variable size; at most 8 bytes)

Filter Mask
+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + + + + + +
Fields: Data Block Element for Filtered Dataset Chunk
Field NameDescription
AddressThe address of the dataset chunk in the file.
Chunk SizeThe size of the dataset chunk in bytes.
Filter MaskIndicates the filter to skip for the dataset chunk. + Each filter has an index number in the pipeline; if that + filter is skipped, the bit corresponding to its index is set.
+ +\section subsec_fmt3_appendixc_appv2btree VII.E. The Version 2 B-trees Index +The Version 2 B-trees index can be used when the dataset fulfills the following condition: + + +Version 2 B-trees can be used to index various objects in the library. See +@ref subsubsec_fmt3_infra_btrees_v2 for more information. The B-tree types +@ref FMT3V2BtType10 "10" and @ref FMT3V2BtType11 "11" record layouts are for +indexing dataset chunks. + +\section sec_fmt3_appendixd VIII. Appendix D: Encoding for Dataspace and Reference + +\section subsec_fmt3_appendixd_encode VIII.A. Dataspace Encoding +#H5Sencode is a public routine that encodes a dataspace description into a buffer while +#H5Sdecode is the corresponding routine that decodes the description encoded in the buffer. +See the reference manual description for these two public routines. + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Dataspace Description for #H5Sencode/#H5Sdecode
bytebytebytebyte
Dataspace IDEncode VersionSize of SizeThis space inserted only to align table nicely

Size of Extent



Dataspace Message (variable size)



Dataspace Selection (variable size)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Dataspace Description for #H5Sencode/#H5Sdecode
Field NameDescription
Dataspace IDThe datspace message ID which is 1.
Encode VersionH5S_ENCODE_VERSION which is 0.
Size of SizeThe number of bytes used to store the size of an object.
Size of ExtentSize of the dataspace message.
Dataspace MessageThe dataspace message information. See @ref subsubsec_fmt3_dataobject_hdr_msg_simple
Dataspace SelectionThe dataspace selection information. See @ref FMT3DataspaceSEL"Dataspace Selection".
+ +\anchor FMT3DataspaceSEL + + + + + + + + + + + + + + +
Layout: Dataspace Selection
bytebytebytebyte
Selection Type

Selection Info (variable size)

+
+ + + + + + + + + + + + + + +
Fields: Dataspace Selection
Field NameDescription
Selection TypeThere are 4 types of selection: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0#H5S_SEL_NONE: Nothing selected
1#H5S_SEL_POINTS: Sequence of points selected
2#H5S_SEL_HYPERSLABS: Hyperslab selected
3#H5S_SEL_ALL: Entire extent selected
Selection InfoThere are 4 types of selection info: + + + + + + + + + + + + + + + + + + + + + +
ValueDescription
0Selection info for #H5S_SEL_NONE Layout and Fields @ref FMT3SelNONE "tables"
1Selection info for #H5S_SEL_POINTS Layout and Fields @ref FMT3SelPOINTS "tables"
2Selection info for #H5S_SEL_HYPERSLABS Layout and Fields @ref FMT3SelHYPER "tables"
3Selection for #H5S_SEL_ALL Layout and Fields @ref FMT3SelALL "tables"
+ +\anchor FMT3SelNONE + + + + + + + + + + + + + + +
Layout: Selection Info for #H5S_SEL_NONE
bytebytebytebyte
Version

Reserved (zero, 8 bytes)

+
+ + + + + + + + + + +
Fields: Selection Info for #H5S_SEL_NONE
Field NameDescription
VersionThe version number for the #H5S_SEL_NONE Selection Info. The value is 1.
+ +\anchor FMT3SelPOINTS + + + + + + + + + + + + + + +
Layout: Selection Info for #H5S_SEL_POINTS
bytebytebytebyte
Version


Points Selection Info (variable size)

+ + + + + + + + + + + + + + + +
Fields: Selection Info for #H5S_SEL_POINTS
Field NameDescription
VersionThe version number for the #H5S_SEL_POINTS Selection Info. The value is either 1 or 2.
Points Selection InfoDepending on version: + + + + + + + + + + + + + +
VersionDescription
1See @ref FMT3SelPOINTSV1 "Version 1 Points Selection Info"
2See @ref FMT3SelPOINTSV2 "Version 2 Points Selection Info"
+ +\anchor FMT3SelPOINTSV1 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Version 1 Points Selection Info
bytebytebytebyte
Reserved (zero)
Length
Rank
Num Points
Point \#1: coordinate \#1
.
.
.
Point \#1: coordinate \#u
.
.
.
Point \#n: coordinate \#1
.
.
.
Point \#n: coordinate \#u
+ + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 1 Points Selection Info
Field NameDescription
LengthThe size in bytes from Length to the end of the selection info.
RankThe number of dimensions.
Num PointsThe number of points in the selection.
Point \#n: coordinate \#uThe array of points in the selection. The points selected are \#1 to \#n where n is + Num Points. The list of coordinates for each point are \#1 to \#u where u is + Rank.
+ +\anchor FMT3SelPOINTSV2 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Version 2 Points Selection Info
bytebytebytebyte
Encode SizeThis space inserted only to align table nicely
Rank
Num Points(2, 4 or 8 bytes)
Point \#1: coordinate \#1(2, 4 or 8 bytes)
.
.
.
Point \#1: coordinate \#u(2, 4 or 8 bytes)
.
.
.
Point \#n: coordinate \#1 (2, 4 or 8 bytes)
.
.
.
Point \#n: coordinate \#u(2, 4 or 8 bytes)
+ + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 2 Points Selection Info
Field NameDescription
Encode SizeThe size for encoding the points selection info which can be 2, 4 or 8 bytes.
RankThe number of dimensions.
Num PointsThe number of points in the selection. The field Encode Size indicates the size + of this field
Point \#n: coordinate \#uThe array of points in the selection. The points selected are \#1 to \#n where n is + Num Points. The list of coordinates for each point are \#1 to \#u where u is + Rank. The field Encode Size indicates the size of this field
+ +\anchor FMT3SelHYPER + + + + + + + + + + + + + + +
Layout: Selection Info for #H5S_SEL_HYPERSLABS
bytebytebytebyte
Version

Hyperslab Selection Info (variable size)

+ + + + + + + + + + + + + + + +
Fields: Selection Info for #H5S_SEL_HYPERSLABS
Field NameDescription
VersionThe version number for the #H5S_SEL_HYPERSLABS selection info. The value is 1, 2 or 3.
Hyperslab Selection InfoDepending on version: + + + + + + + + + + + + + + + + + +
VersionDescription
1See @ref FMT3SelHYPERV1 "Version 1 Hyperslab Selection Info".
2See @ref FMT3SelHYPERV2 "Version 2 Hyperslab Selection Info"
3See @ref FMT3SelHYPERV3 "Version 3 Hyperslab Selection Info"
+ +\anchor FMT3SelHYPERV1 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Version 1 Hyperslab Selection Info
bytebytebytebyte
Reserved
Length
Rank
Num Blocks
Starting Offset \#1 for Block \#1
.
.
.
Starting Offset \#n for Block \#1
Ending Offset \#1 for Block \#1
.
.
.
Ending Offset \#n for Block \#1
.
.
.
.
.
.
.
.
.
Starting Offset \#1 for Block \#u
.
.
.
Starting Offset \#n for Block \#u
Ending Offset \#1 for Block \#u
.
.
.
Ending Offset \#n for Block \#u
+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 1 Hyperslab Selection Info
Field NameDescription
LengthThe size in bytes from the field Rank to the end of the Selection Info.
RankThe number of dimensions in the dataspace.
Num BlocksThe number of blocks in the selection.
Starting Offset \#n for Block \#uThe offset \#n of the starting element in block \#u. \#n is from 1 to Rank. + \#u is from 1 to Num Blocks moving from the fastest changing dimension to + the slowest changing dimension.
Ending Offset \#n for Block \#uThe offset \#n of the ending element in block \#u. \#n is from 1 to Rank. + \#u is from 1 to Num Blocks moving from the fastest changing dimension to + the slowest changing dimension.
+ +\anchor FMT3SelHYPERV2 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Version 2 Hyperslab Selection Info
bytebytebytebyte
FlagsThis space inserted only to align table nicely
Length
Rank
Start \#1 (8 bytes)
Stride \#1 (8 bytes)
Count \#1 (8 bytes)
Block \#1 (8 bytes)
.
.
.
Start \#n (8 bytes)
Stride \#n (8 bytes)
Count \#n (8 bytes)
Block \#n (8 bytes)
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 2 Hyperslab Selection Info
Field NameDescription
FlagsThis is a bit field with the following definition. Currently, this is always set to 0x1. + + + + + + + + + +
BitDescription
0If set, it is a regular hyperslab, otherwise, irregular.
LengthThe size in bytes from the field Rank to the end of the Selection Info.
RankThe number of dimensions in the dataspace.
Start \#nThe offset of the starting element in the block. \#n is from 1 to Rank.
Stride \#nThe number of elements to move in each dimension. \#n is from 1 to Rank.
Count \#nThe number of blocks to select in each dimension. \#n is from 1 to Rank.
Block \#nThe size (in elements) of each block in each dimension. \#n is from 1 to Rank.
+ +\anchor FMT3SelHYPERV3 + + + + + + + + + + + + + + + + + + + +
Layout: Version 3 Hyperslab Selection Info
bytebytebytebyte
FlagsEncode SizeThis space inserted only to align table nicely
Rank

Regular/Irregular Hyperslab Selection Info (variable size)

+ + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 3 Hyperslab Selection Info
Field NameDescription
FlagsThis is a bit field with the following definition: + + + + + + + + + +
BitDescription
0If set, it is a regular hyperslab, otherwise, irregular.
Encode SizeThe size for encoding hyperslab selection info, which can 2, 4 or 8 bytes.
RankThe number of dimensions in the dataspace.
Regular/Irregular Hyperslab Selection InfoThis is the selection info for version 3 hyperslab which can be regular or irregular. + If bit 0 of the field Flags is set, see + @ref FMT3SelHYPERV3REG "Version 3 Regular Hyperslab Selection Info" + Otherwise, see @ref FMT3SelHYPERV3IRREG "Version 3 Irregular Hyperslab Selection Info"
+ +\anchor FMT3SelHYPERV3REG + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Version 3 Regular Hyperslab Selection Info
bytebytebytebyte
Start \#1 (2, 4 or 8 bytes)
Stride \#1 (2, 4 or 8 bytes)
Count \#1 (2, 4 or 8 bytes)
Block \#1 (2, 4 or 8 bytes)
.
.
.
Start \#n (2, 4 or 8 bytes)
Stride \#n (2, 4 or 8 bytes)
Count \#n (2, 4 or 8 bytes)
Block \#n (2, 4 or 8 bytes)
+ + + + + + + + + + + + + + + + + + + + + + + +
Fields: Version 3 Regular Hyperslab Selection Info
Field NameDescription
Start \#nThe offset of the starting element in the block. \#n is from 1 to Rank. + The field Encode Size indicates the size of this field.
Stride \#nThe number of elements to move in each dimension. \#n is from 1 to Rank. + The field Encode Size indicates the size of this field.
Count \#nThe number of blocks to select in each dimension. \#n is from 1 to Rank. + The field Encode Size indicates the size of this field.
Block \#nThe size (in elements) of each block in each dimension. \#n is from 1 to Rank. + The field Encode Size indicates the size of this field.
+ +\anchor FMT3SelHYPERV3IRREG + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Version 3 Irregular Hyperslab Selection Info
bytebytebytebyte
Num Blocks (2, 4 or 8 bytes)
Starting Offset \#1 for Block \#1 (2, 4 or 8 bytes)
.
.
.
Starting Offset \#n for Block \#1 (2, 4 or 8 bytes)
Ending Offset \#1 for Block \#1 (2, 4 or 8 bytes)
.
.
.
Ending Offset \#n for Block \#1 (2, 4 or 8 bytes)
.
.
.
.
.
.
.
.
.
Starting Offset \#1 for Block \#u (2, 4 or 8 bytes)
.
.
.
Starting Offset \#n for Block \#u (2, 4 or 8 bytes)
Ending Offset \#1 for Block \#u (2, 4 or 8 bytes)
.
.
.
Ending Offset \#n for Block \#u (2, 4 or 8 bytes)
+ + + + + + + + + + + + + + + +
Fields: Version 3 Irregular Hyperslab Selection Info
Num BlocksThe number of blocks in the selection. The field Encode Size indicates the size of + this field
Starting Offset \#n for Block \#uThe offset \#n of the starting element in block \#u. \#n is from 1 to Rank. + \#u is from 1 to Num Blocks moving from the fastest changing dimension to the slowest + changing dimension. The field Encode Size indicates the size of this field
Ending Offset \#n for Block \#uThe offset \#n of the ending element in block \#u. \#n is from 1 to Rank. \#u is from + 1 to Num Blocks moving from the fastest changing dimension to the slowest changing + dimension. The field Encode Size indicates the size of this field
+ +\anchor FMT3SelALL + + + + + + + + + + + + + + +
Layout: Selection Info for #H5S_SEL_ALL
bytebytebytebyte
Version

Reserved (zero, 8 bytes)

+
+ + + + + + + + + + +
Fields: Selection Info for #H5S_SEL_ALL
Field NameDescription
VersionThe version number for the #H5S_SEL_ALL Selection Info; the value is 1.
+ +\section subsec_fmt3_appendixd_encoderv VIII.B. Reference Encoding (Revised) +For the following reference type, the Reference Header and Reference Block are stored together +as the dataset's raw data: + + +For the following reference types, the Reference Header plus the @ref FMT3GlobalHeapID "Global Heap ID" +are stored as the dataset's raw data in the file. The global heap ID is used to locate the +Reference Block stored in the global heap: + + + + + + + + + + + + + + + +
Layout: Reference Header
bytebytebytebyte
Reference TypeFlagsThis space inserted only to align table nicely
+ + + + + + + + + + + + + + + +
Fields: Reference Header
Field NameDescription
Reference TypeThere are 3 types of references: + + + + + + + + + + + + + + + + + +
ValueDescription
2#H5R_OBJECT2: Object Reference
3#H5R_DATASET_REGION2: Dataset Region Reference
4#H5R_ATTR: Attribute Reference
FlagsThis field describes the reference: + + + + + + + + + + + + + +
BitDescription
0If set, the reference is to an external file.
1-7Reserved
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Layout: Reference Block
bytebytebytebyte
Token SizeThis space inserted only to align table nicely

Token (variable size)

Length of External File NameThis space inserted only to align table nicely

External File Name (variable size)

Size of Dataspace Selection
Rank of Dataspace Selection

Dataspace Selection Information (variable size)

Length of Attribute Name This space inserted only to align table nicely

Attribute Name (variable size)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Fields: Reference Block
Field NameDescription
Token sizeThis is the size of the token for the object.
TokenThis is the token for the object.
Length of External File NameThis is the length for the external file name.
+ This field exists if bit 0 of flags is set.
External File NameThis is the name of the external file being referenced.
+ This field exists if bit 0 of flags is set. +
Dataspace Selection InformationSee @ref FMT3DataspaceSEL "Dataspace Selection".
+ This field exists if the Reference Type is #H5R_DATASET_REGION2.
Length of Attribute NameThis is the length of the attribute name.
+ This field exists if the Reference Type is #H5R_ATTR.
Attribute NameThis is the name of the attribute being referenced.
+ This field exists if the Reference Type is #H5R_ATTR.
+ +\section subsec_fmt3_appendixd_encodedp VIII.C. Reference Encoding (Backward Compatibility) +The two references described below are maintained to preserve compatibility with previous versions +of the library.
+For the following reference type, the reference encoding is stored as the dataset's raw data in the file: + + +For the following reference type, the @ref FMT3GlobalHeapID "Global Heap ID" is stored as the dataset's +raw data in the file. The global heap ID is used to locate the reference encoding stored in the global heap: + + + + + + + + + + + + + +
Layout: Reference for #H5R_OBJECT1
bytebytebytebyte

Object AddressO

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + +
Fields: Reference for #H5R_OBJECT1
Field NameDescription
Object AddressAddress of the object being referenced
+
+ + + + + + + + + + + + + + +
Layout: Reference for #H5R_DATASET_REGION1
bytebytebytebyte

Object AddressO


Dataspace Selection Information (variable size)

+\li Items marked with an ‘O’ in the above table are of the size specified in + “@ref FMT3SizeOfOffsetsV0 "Size of Offsets"” field in the superblock. + + + + + + + + + + + + + + + +
Fields: Reference for #H5R_DATASET_REGION1
Field NameDescription
Object AddressThis is the address of the object being referenced.
Dataspace Selection InformationThis is the dataspace selection for the object being referenced. See + @ref FMT3DataspaceSEL "Dataspace Selection".
+ +*/ diff --git a/doxygen/dox/Specifications.dox b/doxygen/dox/Specifications.dox index 84cead020b9..f59d0721cf7 100644 --- a/doxygen/dox/Specifications.dox +++ b/doxygen/dox/Specifications.dox @@ -9,10 +9,10 @@ \section File Format -\li \ref FMT1SPEC -\li \ref FMT11SPEC -\li \ref FMT2SPEC -\li \ref FMT3SPEC +\li \ref FMT1 +\li \ref FMT11 +\li \ref FMT2 +\li \ref FMT3 \section Other @@ -21,27 +21,3 @@ \li \ref sec_dim_scales_spec */ - -/** \page FMT3SPEC HDF5 File Format Specification Version 3.0 - -\htmlinclude H5.format.html - -*/ - -/** \page FMT2SPEC HDF5 File Format Specification Version 2.0 - -\htmlinclude H5.format.2.0.html - -*/ - -/** \page FMT11SPEC HDF5 File Format Specification Version 1.1 - -\htmlinclude H5.format.1.1.html - -*/ - -/** \page FMT1SPEC HDF5 File Format Specification Version 1.0 - -\htmlinclude H5.format.1.0.html - -*/ diff --git a/doxygen/examples/H5.format.1.0.html b/doxygen/examples/H5.format.1.0.html deleted file mode 100644 index 00da963c48e..00000000000 --- a/doxygen/examples/H5.format.1.0.html +++ /dev/null @@ -1,4054 +0,0 @@ - - - - HDF5 File Format Specification - - - - -
-
- - - -
-
    -
  1. Introduction -
  2. Disk Format Level 0 - File Signature and Super Block -
  3. Disk Format Level 1 - File Infrastructure - -
      -
    1. Disk Format Level 1A - B-link Trees and B-tree Nodes -
    2. Disk Format Level 1B - Group -
    3. Disk Format Level 1C - Group Entry -
    4. Disk Format Level 1D - Local Heaps -
    5. Disk Format Level 1E - Global Heap -
    6. Disk Format Level 1F - Free-space Index -
    -     -
  4. Disk Format Level 2 - Data Objects - -
      -
    1. Disk Format Level 2a - Data Object Headers -
        -
      1. Name: NIL -
      2. Name: Simple Dataspace - -
      3. Name: Datatype -
      4. Name: Data Storage - Fill Value -
      5. Name: Reserved - not assigned yet -
      -
    -     -
- 		   -
    - -
  1. Disk Format Level 2 - Data Objects - (Continued) -
      -
    1. Disk Format Level 2a - Data Object Headers(Continued) -
        -
      1. Name: Data Storage - Compact -
      2. Name: Data Storage - External Data Files -
      3. Name: Data Storage - Layout -
      4. Name: Reserved - not assigned yet -
      5. Name: Reserved - not assigned yet -
      6. Name: Data Storage - Filter Pipeline -
      7. Name: Attribute -
      8. Name: Object Name -
      9. Name: Object Modification Date and Time -
      10. Name: Shared Object Message -
      11. Name: Object Header Continuation -
      12. Name: Group Message -
      -
    2. Disk Format: Level 2b - Shared Data Object Headers -
    3. Disk Format: Level 2c - Data Object Data Storage -
    -     -
-
-
- -

- - -

Introduction

- - - - - - - -
  -
- HDF5 Groups - 		 
  - Figure 1: Relationships among the HDF5 root group, other groups, and objects -
- 		 
  - HDF5 Objects -  
  - Figure 2: HDF5 objects -- datasets, datatypes, or dataspaces -
- 		 
- - -

The format of an HDF5 file on disk encompasses several - key ideas of the HDF4 and AIO file formats as well as - addressing some shortcomings therein. The new format is - more self-describing than the HDF4 format and is more - uniformly applied to data objects in the file. - -

An HDF5 file appears to the user as a directed graph. - The nodes of this graph are the higher-level HDF5 objects - that are exposed by the HDF5 APIs: - -

- -

At the lowest level, as information is actually written to the disk, - an HDF5 file is made up of the following objects: -

- - The HDF5 library uses these lower-level objects to represent the - higher-level objects that are then presented to the user or - to applications through the APIs. - For instance, a group is an object header that contains a message that - points to a local heap and to a B-tree which points to symbol nodes. - A dataset is an object header that contains messages that describe - datatype, space, layout, filters, external files, fill value, etc - with the layout message pointing to either a raw data chunk or to a - B-tree that points to raw data chunks. - - -

This Document

- -

This document describes the lower-level data objects; - the higher-level objects and their properties are described - in the HDF5 User Guide. - - - - - - -

Three levels of information comprise the file format. - Level 0 contains basic information for identifying and - defining information about the file. Level 1 information contains - the group information (stored as a B-tree) and is used as the - index for all the objects in the file. Level 2 is the rest - of the file and contains all of the data objects, with each object - partitioned into header information, also known as - meta information, and data. - -

The sizes of various fields in the following layout tables are - determined by looking at the number of columns the field spans - in the table. There are three exceptions: (1) The size may be - overridden by specifying a size in parentheses, (2) the size of - addresses is determined by the Size of Offsets field - in the super block, and (3) the size of size fields is determined - by the Size of Lengths field in the super block. - - - -

-

- - -

- Disk Format: Level 0 - File Signature and Super Block

- -

The super block may begin at certain predefined offsets within - the HDF5 file, allowing a block of unspecified content for - users to place additional information at the beginning (and - end) of the HDF5 file without limiting the HDF5 library's - ability to manage the objects within the file itself. This - feature was designed to accommodate wrapping an HDF5 file in - another file format or adding descriptive information to the - file without requiring the modification of the actual file's - information. The super block is located by searching for the - HDF5 file signature at byte offset 0, byte offset 512 and at - successive locations in the file, each a multiple of two of - the previous location, i.e. 0, 512, 1024, 2048, etc. - -

The super block is composed of a file signature, followed by - super block and group version numbers, information - about the sizes of offset and length values used to describe - items within the file, the size of each group page, - and a group entry for the root object in the file. - -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- HDF5 Super Block Layout -
bytebytebytebyte

HDF5 File Signature (8 bytes)

Version # of Super BlockVersion # of Global Free-space StorageVersion # of GroupReserved
Version # of Shared Header Message FormatSize of OffsetsSize of LengthsReserved (zero)
Group Leaf Node KGroup Internal Node K
File Consistency Flags
Base Address*
Address of Global Free-space Heap*
End of File Address*
Driver Information Block Address*
Root Group Address*
- - - -
-
- (Items marked with an asterisk (*) in the above table -
- are of the size specified in "Size of Offsets.") -
-
-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
File SignatureThis 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: - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
decimal13772687013102610
hexadecimal894844460d0a1a0a
ASCII C Notation\211HDF\r\n\032\n
-
-
- - 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.)
Version Number of the Super BlockThis value is used to determine the format of the - information in the super block. When the format of the - information in the super block is changed, the version number - is incremented to the next integer and can be used to - determine how the information in the super block is - formatted.
Version Number of the Global Free-space HeapThis value is used to determine the format of the - information in the Global Free-space Heap.
Version Number of the GroupThis value is used to determine the format of the - information in the Group. When the format of - the information in the Group is changed, the - version number is incremented to the next integer and can be - used to determine how the information in the Group - is formatted.
Version Number of the Shared Header Message FormatThis value is used to determine the format of the - information in a shared object header message, which is - stored in the global small-data heap. Since the format - of the shared header messages differs from the private - header messages, a version number is used to identify changes - in the format.
Size of OffsetsThis 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 super block signature. This - allows a wrapper to be added after the file is created - without invalidating the internal offset locations.
Size of LengthsThis value contains the number of bytes used to store - the size of an object.
Group Leaf Node KEach 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.
Group Internal Node KEach internal node of a group B-tree will have - at least K pointers to other nodes but not more than 2K - pointers. If the group has only one internal - node then it might have fewer than K pointers.
Bytes per B-tree PageThis value contains the number of bytes used for symbol - pairs per page of the B-trees used in the file. All - B-tree pages will have the same size per page. -
- For 32-bit file offsets, 340 objects is the maximum - per 4KB page; for 64-bit file offset, 254 objects will fit - per 4KB page. In general, the equation is: -
-    <number of objects> = -
       - FLOOR((<page size> - <offset size>) / -
          - (<Symbol size> + <offset size>)) - - 1
File Consistency FlagsThis value contains flags to indicate information - about the consistency of the information contained - within the file. Currently, the following bit flags are - defined: -
    -
  • Bit 0 set indicates that the file is opened for - write-access. -
  • Bit 1 set indicates that the file has - been verified for consistency and is guaranteed to be - consistent with the format defined in this document. -
  • Bits 2-31 are reserved for future use. -
- Bit 0 should be - set as the first action when a file is opened for write - access and should be cleared only as the final action - when closing a file. Bit 1 should be cleared during - normal access to a file and only set after the file's - consistency is guaranteed by the library or a - consistency utility.
Base AddressThis 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 super block itself when creating new files; - future versions of the library may provide greater - flexibility. Unless otherwise noted, - all other file addresses are relative to this base - address.
Address of Global Free-space HeapFree-space management is not yet defined in the HDF5 - file format and is not handled by the library. - Currently this field always contains the - undefined address 0xfff...ff. - -
End of File AddressThis is the relative file address of the first byte past - the end of all HDF5 data. It is used to determine whether a - file has been accidentally truncated and as an address where - file data allocation can occur if the free list is not - used.
Driver Information Block AddressThis 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 (all bits set).
Root Group AddressThis is the address of the root group (described later - in this document), which serves as the entry point into - the group graph.
-
- - -

The file driver information block is an optional region of the - file which contains information needed by the file driver in - order to reopen a file. The format of the file driver information - block is: - -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - -
- Driver Information Block -
bytebytebytebyte
VersionReserved (zero)
Driver Information Size (4 bytes)

Driver Identification (8 bytes)



Driver Information


-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
VersionThe version number of the driver information block. The - file format documented here is version zero.
Driver Information SizeThe size in bytes of the Driver Information part of this - structure.
Driver IdentificationThis is an eight-byte ASCII string without null - termination which identifies the driver and version number - of the Driver Information block. The predefined drivers - supplied with the HDF5 library are 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. - For example, the various versions of the family driver - will be identified by NCSAfami, NCSAfam0, - NCSAfam1, etc. - (NCSAfami is simply NCSAfamily truncated - to eight characters. Subsequent identifiers will be created by - substituting sequential numerical values for the final character, - starting with zero.) -

- Identification for user-defined drivers - is arbitrary but should be unique.

Driver InformationDriver information is stored in a format defined by the - file driver and encoded/decoded by the driver callbacks - invoked from the H5FD_sb_encode and - H5FD_sb_decode functions.
-
- - -

-

- - -

- Disk Format: Level 1 - File Infrastructure

-

Disk Format: Level 1A - B-link Trees and B-tree Nodes

- -

B-link trees allow flexible storage for objects which tend to grow - in ways that cause the object to be stored discontiguously. B-trees - are described in various algorithms books including "Introduction to - Algorithms" by Thomas H. Cormen, Charles E. Leiserson, and Ronald - L. Rivest. The B-link tree, in which the sibling nodes at a - particular level in the tree are stored in a doubly-linked list, - is described in the "Efficient Locking for Concurrent Operations - on B-trees" paper by Phillip Lehman and S. Bing Yao as published - in the ACM Transactions on Database Systems, Vol. 6, - No. 4, December 1981. - -

The B-link trees implemented by the file format contain one more - key than the number of children. In other words, each child - pointer out of a B-tree node has a left key and a right key. - The pointers out of internal nodes point to sub-trees while - the pointers out of leaf nodes point to symbol nodes and - raw data chunks. - Aside from that difference, internal nodes and leaf nodes - are identical. - -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- B-tree Nodes -
bytebytebytebyte
Node Signature
Node TypeNode LevelEntries Used
Address of Left Sibling
Address of Right Sibling
Key 0 (variable size)
Address of Child 0
Key 1 (variable size)
Address of Child 1
...
Key 2K (variable size)
Address of Child 2K
Key 2K+1 (variable size)
-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Node SignatureThe ASCII character string TREE is - used to indicate the - beginning of a B-link tree node. This gives file - consistency checking utilities a better chance of - reconstructing a damaged file.
Node TypeEach B-link 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. -
-
-
0 -
This tree points to group nodes. -
1 -
This tree points to a new data chunk. -
-
Node LevelThe 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 UsedThis 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 SiblingThis is the file address of the left sibling of the - current node relative to the super block. If the current - node is the left-most node at this level then this field - is the undefined address (all bits set).
Address of Right SiblingThis is the file address of the right sibling of the - current node relative to the super block. If the current - node is the right-most node at this level then this - field is the undefined address (all bits set).
Keys and Child PointersEach 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 Entries Used field. If - that field is N then the B-link tree contains - N child pointers and N+1 keys.
KeyThe 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 1, the key is formatted as follows: -

- - - - - - - - - - - -
Bytes 1-4Size of chunk in bytes.
Bytes 4-8Filter mask, a 32-bit bitfield indicating which - filters have been applied to that chunk.
N fields of 8 bytes eachA 64-bit index indicating the offset of the - chunk within the dataset where N is the number - of dimensions of the dataset. For example, if - a chunk in a 3-dimensional dataset begins at the - position [5,5,5], there will be three - such 8-bit indices, each with the value of - 5.
-
-

- For nodes of node type 0, the key is formatted as follows: -

- - - - - -
A single field of Size of Lengths - bytesIndicates the byte offset into the local heap - for the first object name in the subtree which - that key describes.
-
-
Child PointersThe tree node contains file addresses of subtrees or - data depending on the node level. Nodes at Level 0 point - to data addresses, either data chunk or group nodes. - Nodes at non-zero levels point to other nodes of the - same B-tree.
-
- -

- Each B-tree node looks like this: - -

- - - - - - - - - - - - - -
key[0]  child[0]  key[1]  child[1]  key[2]  ...  ...  key[N-1]  child[N-1]  key[N]
-
- - where child[i] is a pointer to a sub-tree (at a level - above Level 0) or to data (at Level 0). - Each key[i] describes an item stored by the B-tree - (a chunk or an object of a group node). The range of values - represented by child[i] are indicated by key[i] - and key[i+1]. - - -

The following question must next be answered: - "Is the value described by key[i] contained in - child[i-1] or in child[i]?" - The answer depends on the type of tree. - In trees for groups (node type 0) the object described by - key[i] is the greatest object contained in - child[i-1] while in chunk trees (node type 1) the - chunk described by key[i] is the least chunk in - child[i]. - -

That means that key[0] for group trees is sometimes unused; - it points to offset zero in the heap, which is always the - empty string and compares as "less-than" any valid object name. - -

And key[N] for chunk trees is sometimes unused; - it contains a chunk offset which compares as "greater-than" - any other chunk offset and has a chunk byte size of zero - to indicate that it is not actually allocated. - - -

Disk Format: Level 1B - Group and Symbol Nodes

- -

A group is an object internal to the file that allows - arbitrary nesting of objects (including other groups). - A group maps a set of names to a set of file - address relative to the base address. Certain meta data - for an object to which the group points can be duplicated - in the group symbol table in addition to the object header. - -

An HDF5 object name space can be stored hierarchically by - partitioning the name into components and storing each - component in a group. The group entry for a - non-ultimate component points to the group containing - the next component. The group entry for the last - component points to the object being named. - -

A group is a collection of group nodes pointed - to by a B-link tree. Each group node contains entries - for one or more symbols. If an attempt is made to add a - symbol to an already full group node containing - 2K entries, then the node is split and one node - contains K symbols and the other contains - K+1 symbols. - -

-

- - - - - - - - - - - - - - - - - - - -
- Group Node (A Leaf of a B-tree) -
bytebytebytebyte
Node Signature
Version NumberReserved for Future UseNumber of Symbols


Group Entries


-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Node SignatureThe ASCII character string SNOD is - used to indicate the - beginning of a group node. This gives file - consistency checking utilities a better chance of - reconstructing a damaged file.
Version NumberThe version number for the group node. This - document describes version 1.
Number of SymbolsAlthough all group nodes have the same length, - most contain fewer than the maximum possible number of - symbol entries. This field indicates how many entries - contain valid data. The valid entries are packed at the - beginning of the group node while the remaining - entries contain undefined values.
Group EntriesEach symbol has an entry in the group node. - The format of the entry is described below.
-
- -

- Disk Format: Level 1C - Group Entry

- -

Each group entry in a group node is designed - to allow for very fast browsing of stored objects. - Toward that design goal, the group entries - include space for caching certain constant meta data from the - object header. - -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Group Entry -
bytebytebytebyte
Name Offset (<size> bytes)
Object Header Address
Cache Type
Reserved


Scratch-pad Space (16 bytes)


-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Name OffsetThis is the byte offset into the group local - heap for the name of the object. The name is null - terminated.
Object Header AddressEvery object has an object header which serves as a - permanent location for the object's meta data. In addition - to appearing in the object header, some meta data can be - cached in the scratch-pad space.
Cache TypeThe cache type is determined from the object header. - It also determines the format for the scratch-pad space. -
-
-
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 -
Object header meta data is cached in the group - entry. This implies that the group - 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. - -
N -
Other cache values can be defined later and - libraries that do not understand the new values will - still work properly. -
-
ReservedThese 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 SpaceThis space is used for different purposes, depending - on the value of the Cache Type field. Any meta-data - about a dataset object represented in the scratch-pad - space is duplicated in the object header for that - dataset. This meta data can include the datatype - and the size of the dataspace for a dataset whose datatype - is atomic and whose dataspace is fixed and less than - four dimensions. - Furthermore, no data is cached in the group - entry scratch-pad space if the object header for - the group entry has a link count greater than - one.
-
- -

Format of the Scratch-pad Space

- -

The group entry scratch-pad space is formatted - according to the value in the Cache Type field. - -

If the Cache Type field contains the value zero - (0) then no information is - stored in the scratch-pad space. - -

If the Cache Type field contains the value one - (1), then the scratch-pad space - contains cached meta data for another object header - in the following format: - -

-

- - - - - - - - - - - - - - -
- Object Header Scratch-pad Format -
bytebytebytebyte
Address of B-tree
Address of Name Heap
-
- -

-

- - - - - - - - - - - - - - - -
Field NameDescription
Address of B-treeThis is the file address for the root of the - group's B-tree.
Address of Name HeapThis is the file address for the group's local - heap, in which are stored the symbol names.
-
- - -

If the Cache Type field contains the value two - (2), then the scratch-pad space - contains cached meta data for another symbolic link - in the following format: - -

-

- - - - - - - - - - - - - -
- Symbolic Link Scratch-pad Format -
bytebytebytebyte
Offset to Link Value
-
- -

-

- - - - - - - - - - -
Field NameDescription
Offset to Link ValueThe 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.
-
- -

Disk Format: Level 1D - Local Heaps

- -

A heap is a collection of small heap objects. Objects can be - inserted and removed from the heap at any time. - The address of a heap does not change once the heap is created. - References to objects are stored in the group table; - the names of those objects are stored in the local heap. - -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Local Heaps -
bytebytebytebyte
Heap Signature
Reserved (zero)
Data Segment Size
Offset to Head of Free-list (<size> bytes)
Address of Data Segment
-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Heap SignatureThe 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.
Data Segment SizeThe total amount of disk memory allocated for the heap - data. This may be larger than the amount of space - required by the object stored in the heap. The extra - unused space holds a linked list of free blocks.
Offset to Head of Free-listThis is the offset within the heap data segment of the - first free block (or all 0xff bytes if there is no free - block). The free block contains <size> bytes that - are the offset of the next free chunk (or all 0xff bytes - if this is the last free chunk) followed by <size> - bytes that store the size of this free chunk.
Address of Data SegmentThe 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.
-
- -

Objects within the heap should be aligned on an 8-byte boundary. - -

Disk Format: Level 1E - Global Heap

- -

Each HDF5 file has a global heap which stores various types of - information which is typically shared between datasets. The - global heap was designed to satisfy these goals: - -

    -
  1. Repeated access to a heap object must be efficient without - resulting in repeated file I/O requests. Since global heap - objects will typically be shared among several datasets, it is - probable that the object will be accessed repeatedly. - -

    -
  2. Collections of related global heap objects should result in - fewer and larger I/O requests. For instance, a dataset of - void pointers will have a global heap object for each - pointer. Reading the entire set of void pointer objects - should result in a few large I/O requests instead of one small - I/O request for each object. - -

    -
  3. It should be possible to remove objects from the global heap - and the resulting file hole should be eligible to be reclaimed - for other uses. -

    -
- -

The implementation of the heap makes use of the memory - management already available at the file level and combines that - with a new top-level object called a collection to - achieve Goal B. The global heap is the set of all collections. - Each global heap object belongs to exactly one collection and - each collection contains one or more global heap objects. For - the purposes of disk I/O and caching, a collection is treated as - an atomic object. - -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- A Global Heap Collection -
bytebytebytebyte
Magic Number
VersionReserved
Collection Size

Global Heap Object 1 - (described below)


Global Heap Object 2


...


Global Heap Object N


Global Heap Object 0 (free space)

-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Magic NumberThe magic number for global heap collections are the - four bytes G, C, O, - and L.
VersionEach collection has its own version number so that new - collections can be added to old files. This document - describes version zero of the collections. -
Collection Data SizeThis 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 and which allows for 170 16-byte heap - objects plus their overhead.
Object 1 through NThe objects are stored in any order with no - intervening unused space.
Object 0Object 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 the collection contains no free space. -
-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - -
- Global Heap Object -
bytebytebytebyte
Object IDReference Count
Reserved
Object Data Size

Object Data

-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Object IDEach 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 CountAll 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.
ReservedZero padding to align next field on an 8-byte - boundary.
Object Size This is the size of the fields - above plus the object data stored for the object. The - actual storage size is rounded up to a multiple of - eight.
Object DataThe object data is treated as a one-dimensional array - of bytes to be interpreted by the caller.
-
- -

Disk Format: Level 1F - Free-space Heap

- -

The Free-space Index is a collection of blocks of data, - dispersed throughout the file, which are currently not used by - any file objects. - -

The super block contains a pointer to root of the free-space description; - that pointer is currently (i.e., in HDF5 Release 1.2) required - to be the undefined address 0xfff...ff. - -

The free-sapce index is not otherwise publicly defined at this time. - - - - - -

-

- - -

Disk Format: Level 2 - Data Objects

- -

Data objects contain the real information in the file. These - objects compose the scientific data and other information which - are generally thought of as "data" by the end-user. All the - other information in the file is provided as a framework for - these data objects. - -

A data object is composed of header information and data - information. The header information contains the information - needed to interpret the data information for the data object as - well as additional "meta-data" or pointers to additional - "meta-data" used to describe or annotate each data object. - -

- Disk Format: Level 2a - Data Object Headers

- -

The header information of an object is designed to encompass - all the information about an object which would be desired to be - known, except for the data itself. This information includes - the dimensionality, number-type, information about how the data - is stored on disk (in external files, compressed, broken up in - blocks, etc.), as well as other information used by the library - to speed up access to the data objects or maintain a file's - integrity. The header of each object is not necessarily located - immediately prior to the object's data in the file and in fact - may be located in any position in the file. - -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Object Headers -
bytebytebytebyte
Version # of Object HeaderReservedNumber of Header Messages
Object Reference Count

Total Object Header Size

Header Message Type #1Size of Header Message Data #1
FlagsReserved

Header Message Data #1

.
.
.
Header Message Type #nSize of Header Message Data #n
FlagsReserved

Header Message Data #n

-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Version number of the object headerThis value is used to determine the format of the - information in the object header. When the format of the - information in 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.
ReservedAlways set to zero.
Number of header messagesThis value determines the number of messages listed in - this object header. This provides a fast way for software - to prepare storage for the messages in the header.
Object Reference CountThis value specifies the number of references to this - object within the current file. References to the - data object from external files are not tracked.
Total Object Header SizeThis value specifies the total number of bytes of header - message data following this length field for the current - message as well as any continuation data located elsewhere - in the file.
Header Message TypeThe header message type specifies the type of - information included in the header message data following - the type along with a small amount of other information. - Bit 15 of the message type is set if the message is - constant (constant messages cannot be changed since they - may be cached in group entries throughout the - file). The header message types for the pre-defined - header messages will be included in further discussion - below.
Size of Header Message DataThis 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.
FlagsThis is a bit field with the following definition: -
-
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 stored in the global heap and - the Header Message Data field contains a Shared Object - message and the Size of Header Message Data field - contains the size of that Shared Object message. -
2-7 -
Reserved -
-
Header Message DataThe 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 zeros to make the - size a multiple of eight.
-
- -

The header message types and the message data associated with - them compose the critical "meta-data" about each object. Some - header messages are required for each object while others are - optional. Some optional header messages may also be repeated - several times in the header itself, the requirements and number - of times allowed in the header will be noted in each header - message description below. - -

The following is a list of currently defined header messages: - -

-

Name: NIL

- Type: 0x0000
- Length: varies
- Status: Optional, may be repeated.
- Purpose and Description: The NIL message is used to - indicate a message - which is to be ignored when reading the header messages for a data object. - [Probably one which has been deleted for some reason.]
- Format of Data: Unspecified.
- - - - -
-

Name: Simple Dataspace

- - Type: 0x0001
- Length: Varies according to the number of dimensions, - as described in the following table
- Status: The Simple Dataspace message is required - and may not be repeated. This message is currently used with - datasets and named dataspaces.
- -

The Simple Dataspace message describes the number - of dimensions and size of each dimension that the data object - has. This message is only used for datasets which have a - simple, rectilinear grid layout; datasets requiring a more - complex layout (irregularly structured or unstructured grids, etc.) - must use the Complex Dataspace message for expressing - the space the dataset inhabits. - (Note: The Complex Dataspace functionality is - not yet implemented (as of HDF5 Release 1.2). It is not described - in this document.) - -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Simple Dataspace Message -
bytebytebytebyte
VersionDimensionalityFlagsReserved
Reserved
Dimension Size #1 (<size> bytes)
.
.
.
Dimension Size #n (<size> bytes)
Dimension Maximum #1 (<size> bytes)
.
.
.
Dimension Maximum #n (<size> bytes)
Permutation Index #1
.
.
.
Permutation Index #n
-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Version This value is used to determine the format of the - Simple 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.
DimensionalityThis value is the number of dimensions that the data - object has.
FlagsThis 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 for each dimension.
Dimension Size #n (<size> bytes)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 Maximum #n (<size> bytes)This value is the maximum size of the dimension of the - data as stored in the file. This value may be the special - value <UNLIMITED> (all bits set) which indicates - that the data may expand along this dimension - indefinitely. If these values are not stored, the maximum - value of each dimension is assumed to be the same as the - current size value.
Permutation Index #n (4 bytes)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.
-
- - - - - - - -
-

Name: Datatype

- - Type: 0x0003
- Length: variable
- Status: One required per dataset or named datatype
- -

The datatype message defines the datatype for each data point - of a dataset. A datatype can describe an atomic type like a - fixed- or floating-point type or a compound type like a C - struct. A datatype does not, however, describe how data points - are combined to produce a dataset. Datatypes are stored on disk - as a datatype message, which is a list of datatype classes and - their associated properties. - -

-

- - - - - - - - - - - - - - - - - - - - - - -
- Datatype Message -
bytebytebytebyte
Type Class and VersionClass Bit Field
Size in Bytes (4 bytes)


Properties


-
- -

The Class Bit Field and Properties fields vary depending - on the Type Class, which is the low-order four bits of the Type - Class and Version field (the high-order four bits are the - version, which should be set to the value one). The type class - is one of 0 (fixed-point number), 1 (floating-point number), - 2 (date and time), 3 (text string), 4 (bit field), 5 (opaque), - 6 (compound), 7 (reference), 8 (enumeration), or 9 (variable-length). - The Class Bit Field is zero and the size of the - Properties field is zero except for the cases noted here. - -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Bit Field for Fixed-point Numbers (Class 0) -
BitsMeaning
0Byte Order. If zero, byte order is little-endian; - otherwise, byte order is big endian.
1, 2Padding type. Bit 1 is the lo_pad type and bit 2 - is the hi_pad type. If a datum has unused bits at either - end, then the lo_pad or hi_pad bit is copied to those - locations.
3Signed. If this bit is set then the fixed-point - number is in 2's complement form.
4-23Reserved (zero).
-
- -

-

- - - - - - - - - - - - - - -
- Properties for Fixed-point Numbers (Class 0) -
ByteByteByteByte
Bit OffsetBit Precision
-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Bit Field for Floating-point Numbers (Class 1) -
BitsMeaning
0Byte Order. If zero, byte order is little-endian; - otherwise, byte order is big endian.
1, 2, 3Padding type. Bit 1 is the low bits pad type, bit 2 - is the high bits pad type, and bit 3 is the internal bits - pad type. If a datum has unused bits at either or between - the sign bit, exponent, or mantissa, then the value of bit - 1, 2, or 3 is copied to those locations.
4-5Normalization. The value can be 0 if there is no - normalization, 1 if the most significant bit of the - mantissa is always set (except for 0.0), and 2 if the most - significant bit of the mantissa is not stored but is - implied to be set. The value 3 is reserved and will not - appear in this field.
6-7Reserved (zero).
8-15Sign. This is the bit position of the sign - bit.
16-23Reserved (zero).
-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - -
- Properties for Floating-point Numbers (Class 1) -
ByteByteByteByte
Bit OffsetBit Precision
Exponent LocationExponent Size in BitsMantissa LocationMantissa Size in Bits
Exponent Bias
-
- -

-

- - - - - - - - - - - - - - - - - - - - - -
- Bit Field for Strings (Class 3) -
BitsMeaning
0-3Padding type. This four-bit value determines the - type of padding to use for the string. The values are: - -
-
0 Null terminate. -
A zero byte marks the end of the string and is - guaranteed to be present after converting a long - string to a short string. When converting a short - string to a long string the value is padded with - additional null characters as necessary. - -

-
1 Null pad. -
Null characters are added to the end of the value - during conversions from short values to long values - but conversion in the opposite direction simply - truncates the value. - -

-
2 Space pad. -
Space characters are added to the end of the value - during conversions from short values to long values - but conversion in the opposite direction simply - truncates the value. This is the Fortran - representation of the string. - -

-
3-15 Reserved. -
These values are reserved for future use. -
-
4-7Character Set. The character set to use for - encoding the string. The only character set supported is - the 8-bit ASCII (zero) so no translations have been defined - yet.
8-23Reserved (zero).
-
- -

-

- - - - - - - - - - - - - - - - - - - - - - -
- Bit Field for Bitfield Types (Class 4) -
BitsMeaning
0Byte Order. If zero, byte order is little-endian; - otherwise, byte order is big endian.
1, 2Padding type. Bit 1 is the lo_pad type and bit 2 - is the hi_pad type. If a datum has unused bits at either - end, then the lo_pad or hi_pad bit is copied to those - locations.
3-23Reserved (zero).
-
- -

-

- - - - - - - - - - - - - - -
- Properties for Bitfield Types (Class 4) -
ByteByteByteByte
Bit OffsetBit Precision
-
- -

-

- - - - - - - - - - - - -
- Bit Field for Opaque Types (Class 5) -
BitsMeaning
0-23Reserved (zero).
-
- -

-

- - - - - - - - - - - - - -
- Properties for Opaque Types (Class 5) -
ByteByteByteByte

Null-terminated ASCII Tag
- (multiple of 8 bytes)

-
- -

-

- - - - - - - - - - - - - - - - -
- Bit Field for Compound Types (Class 6) -
BitsMeaning
0-15Number of Members. This field contains the number - of members defined for the compound datatype. The member - definitions are listed in the Properties field of the data - type message. -
15-23Reserved (zero).
-
- -

The Properties field of a compound datatype is a list of the - member definitions of the compound datatype. The member - definitions appear one after another with no intervening bytes. - The member types are described with a recursive datatype - message. - -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Properties for Compound Types (Class 6) -
ByteByteByteByte


Name (null terminated, multiple of - eight bytes)


Byte Offset of Member in Compound Instance
Dimensionalityreserved
Dimension Permutation
Reserved
Size of Dimension 0 (required)
Size of Dimension 1 (required)
Size of Dimension 2 (required)
Size of Dimension 3 (required)


Member Type Message


-
- -

-

- - - - - - - - - - - - - - - - - -
- Bit Field for Enumeration Types (Class 8) -
BitsMeaning
0-15Number of Members. The number of name/value - pairs defined for the enumeration type.
16-23Reserved (zero).
-
- -

-

- - - - - - - - - - - - - - - - - - - - - - -
- Properties for Enumeration Types (Class 8) -
ByteByteByteByte

Parent Type


Names


Values

-
- -
- - - - - - - - - - - -
Parent Type:Each enumeration type is based on some parent type, - usually an integer. The information for that parent type is - described recursively by this field.
Names:The name for each name/value pair. Each name is - stored as a null terminated ASCII string in a multiple of - eight bytes. The names are in no particular order.
Values:The list of values in the same order as the names. - The values are packed (no inter-value padding) and the - size of each value is determined by the parent type.
-
- - -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Bit Field for Variable-length Types (Class 9) -
BitsMeaning
0-3
Type
-
0 Variable-length sequence
-
This variable-length datatype can be of any sequence - of data. Variable-length sequences do not have padding - or character set information.
-
1 Variable-length string
-
This variable-length datatype is composed of a series of - characters. Variable-length strings have padding and - character set information.
-
4-7
Padding type (variable-length string only)
-
This four-bit value determines the type of padding - used for variable-length strings. The values are the same - as for the string padding type, as follows:
-
0 Null terminate
-
A zero byte marks the end of a string and is guaranteed - to be present after converting a long string to a short - string. When converting a short string to a long string, - the value is padded with additional null characters - as necessary. -
1 Null pad
-
Null characters are added to the end of the value - during conversion from a short string to a longer string. - Conversion from a long string to a shorter string - simply truncates the value.
-
2 Space pad
-
Space characters are added to the end of the value - during conversion from a short string to a longer string. - Conversion from a long string to a shorter string simply - truncates the value. - This is the Fortran representation of the string. -
-
3-15 Reserved
-
These values are reserved for future use.
-
8-11
Character set (variable-length string only)
-
This four-bit value specifies the character set - to be used for encoding the string.
-
0 8-bit ASCII
-
As of this writing (July 2002, Release 1.4.4), - 8-bit ASCII is the only character set supported. - Therefore, no translations have been defined.
-
12-23Reserved (zero).
-
- -

-

- - - - - - - - - - - - - - -
- Properties for Variable-length Types (Class 9) -
ByteByteByteByte

Parent Type

-
- -
- - - - - -
Parent Type:Each variable-length type is based on - some parent type. The information for that parent type is - described recursively by this field.
-
- - - -

- - - - -

-

Name: Data Storage - Fill Value

- Type: 0x0004
- Length: varies
- Status: Optional, may not be repeated.
- -

The fill value message stores a single data point value which - is returned to the application when an uninitialized data point - is read from the dataset. The fill value is interpreted with - the same datatype as the dataset. If no fill value message is - present then a fill value of all zero is assumed. - -

-

- - - - - - - - - - - - - - - - - -
- Fill Value Message -
bytebytebytebyte
Size (4 bytes)

Fill Value

-
- -

-

- - - - - - - - - - - - - - - -
Field NameDescription
Size (4 bytes)This is the size of the Fill Value field in bytes.
Fill ValueThe fill value. The bytes of the fill value are - interpreted using the same datatype as for the dataset.
-
- -
-

Name: Reserved - Not Assigned Yet

- Type: 0x0005
- Length: N/A
- Status: N/A
- - - -
-

Name: Data Storage - Compact

- - Type: 0x0006
- Length: varies
- Status: Optional, may not be repeated.
- -

This message indicates that the data for the data object is - stored within the current HDF file by including the actual - data as the header data for this message. The data is - stored internally in - the normal format, i.e. in one chunk, uncompressed, etc. - -

Note that one and only one of the Data Storage headers can be - stored for each data object. - -

Format of Data: The message data is actually composed - of dataset data, so the format will be determined by the dataset - format. - - - -

-

Name: Data Storage - - External Data Files

- Type: 0x0007
- Length: varies
- Status: Optional, may not be repeated.
- -

Purpose and Description: The external object message - indicates that the data for an object is stored outside the HDF5 - file. The filename of the object is stored as a Universal - Resource Location (URL) of the actual filename containing the - data. An external file list record also contains the byte offset - of the start of the data within the file and the amount of space - reserved in the file for that data. - -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- External File List Message -
bytebytebytebyte
VersionReserved
Allocated SlotsUsed Slots

Heap Address


Slot Definitions...

-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Version This value is used to determine the format of the - External File List 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.
ReservedThis field is reserved for future use.
Allocated SlotsThe 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.
Used SlotsThe number of initial slots which contain valid - information. The remaining slots are zero filled.
Heap AddressThis is the address of a local name heap which contains - the names for the external files. The name at offset zero - in the heap is always the empty string.
Slot DefinitionsThe slot definitions are stored in order according to - the array addresses they represent. If more slots have - been allocated than what has been used then the defined - slots are all at the beginning of the list.
-
- -

-

- - - - - - - - - - - - - - - - - - - - - -
- External File List Slot -
bytebytebytebyte

Name Offset (<size> bytes)


File Offset (<size> bytes)


Size

-
- -

-

- - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Name Offset (<size> bytes)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).
File Offset (<size> bytes)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.
SizeThis 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 zeros - past the end of the file without failing.
-
- - -
-

Name: Data Storage - Layout

- - Type: 0x0008
- Length: varies
- Status: Required for datasets, may not be repeated. - -

Purpose and Description: Data layout describes how the - elements of a multi-dimensional array are arranged in the linear - address space of the file. Two types of data layout are - supported: - -

    -
  1. The array can be stored in one contiguous area of the file. - The layout requires that the size of the array be constant and - does not permit chunking, compression, checksums, encryption, - etc. The message stores the total size of the array and the - offset of an element from the beginning of the storage area is - computed as in C. - -
  2. The array domain can be regularly decomposed into chunks and - each chunk is allocated separately. This layout supports - arbitrary element traversals, compression, encryption, and - checksums, and the chunks can be distributed across external - raw data files (these features are described in other - messages). The message stores the size of a chunk instead of - the size of the entire array; the size of the entire array can - be calculated by traversing the B-tree that stores the chunk - addresses. -
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Data Layout Message -
bytebytebytebyte
VersionDimensionalityLayout ClassReserved
Reserved

Address

Dimension 0 (4-bytes)
Dimension 1 (4-bytes)
...
-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
VersionA version number for the layout message. This - documentation describes version one.
DimensionalityAn array has a fixed dimensionality. This field - specifies the number of dimension size fields later in the - message.
Layout ClassThe layout class specifies how the other fields of the - layout message are to be interpreted. A value of one - indicates contiguous storage while a value of two - indicates chunked storage. Other values will be defined - in the future.
AddressFor contiguous storage, this is the address of the first - byte of storage. For chunked storage this is the address - of the B-tree that is used to look up the addresses of the - chunks.
DimensionsFor contiguous storage the dimensions define the entire - size of the array while for chunked storage they define - the size of a single chunk.
-
- - -
-

Name: Reserved - Not Assigned Yet

- Type: 0x0009
- Length: N/A
- Status: N/A
- Purpose and Description: N/A
- Format of Data: N/A - -
-

Name: Reserved - Not Assigned Yet

- Type: 0x000A
- Length: N/A
- Status: N/A
- Purpose and Description: N/A
- Format of Data: N/A - -
-

Name: Data Storage - Filter Pipeline

- Type: 0x000B
- Length: varies
- Status: Optional, may not be repeated. - -

Purpose and Description: This message describes the - filter pipeline which should be applied to the data stream by - providing filter identification numbers, flags, a name, an - client data. - -

-

- - - - - - - - - - - - - - - - - - - - - - - -
- Filter Pipeline Message -
bytebytebytebyte
VersionNumber of FiltersReserved
Reserved

Filter List

-
- -

-

- - - - - - - - - - - - - - - - - - - - -
Field NameDescription
VersionThe version number for this message. This document - describes version one.
Number of FiltersThe total number of filters described by this - message. The maximum possible number of filters in a - message is 32.
Filter ListA description of each filter. A filter description - appears in the next table.
-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Filter Pipeline Message -
bytebytebytebyte
Filter IdentificationName Length
FlagsClient Data Number of Values

Name


Client Data

Padding
-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Filter IdentificationThis is a unique (except in the case of testing) - identifier for the filter. Values from zero through 255 - are reserved for filters defined by the NCSA HDF5 - library. Values 256 through 511 have been set aside for - use when developing/testing new filters. The remaining - values are allocated to specific filters by contacting the - HDF5 development team. -
Name LengthEach filter has an optional null-terminated ASCII name - and this field holds the length of the name including the - null termination padded with nulls to be a multiple of - eight. If the filter has no name then a value of zero is - stored in this field.
FlagsThe flags indicate certain properties for a filter. The - bit values defined so far are: - -
-
bit 1 -
If set then the filter is an optional filter. - During output, if an optional filter fails it will be - silently removed from the pipeline. -
-
Client Data Number of ValuesEach filter can store a few integer values to control - how the filter operates. The number of entries in the - Client Data array is stored in this field.
NameIf the Name Length field is non-zero then it will - contain the size of this field, a multiple of eight. This - field contains a null-terminated, ASCII character - string to serve as a comment/name for the filter.
Client DataThis is an array of four-byte integers which will be - passed to the filter function. The Client Data Number of - Values determines the number of elements in the - array.
PaddingFour bytes of zeros are added to the message at this - point if the Client Data Number of Values field contains - an odd number.
-
- -
-

Name: Attribute

- Type: 0x000C
- Length: varies
- Status: Optional, may be repeated.
- -

Purpose and Description: The Attribute - message is used to list objects in the HDF file which are used - as attributes, or "meta-data" about the current object. An - attribute is a small dataset; it has a name, a datatype, a data - space, and raw data. Since attributes are stored in the object - header they must be relatively small (<64kb) and can be - associated with any type of object which has an object header - (groups, datasets, named types and spaces, etc.). - -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Attribute Message -
bytebytebytebyte
VersionReservedName Size
Type SizeSpace Size

Name


Type


Space


Data

-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
VersionVersion number for the message. This document describes - version 1 of attribute messages.
ReservedThis field is reserved for later use and is set to - zero.
Name SizeThe length of the attribute name in bytes including the - null terminator. Note that the Name field below may - contain additional padding not represented by this - field.
Type SizeThe length of the datatype description in the Type - field below. Note that the Type field may contain - additional padding not represented by this field.
Space SizeThe length of the dataspace description in the Space - field below. Note that the Space field may contain - additional padding not represented by this field.
NameThe null-terminated attribute name. This field is - padded with additional null characters to make it a - multiple of eight bytes.
TypeThe datatype description follows the same format as - described for the datatype object header message. This - field is padded with additional zero bytes to make it a - multiple of eight bytes.
SpaceThe dataspace description follows the same format as - described for the dataspace object header message. This - field is padded with additional zero bytes to make it a - multiple of eight bytes.
DataThe raw data for the attribute. The size is determined - from the datatype and dataspace descriptions. This - field is not padded with additional zero - bytes.
-
- -
-

Name: Object Name

- -

Type: 0x000D
- Length: varies
- Status: Optional, may not be repeated. - -

Purpose and Description: The object name or comment is - designed to be a short description of an object. An object name - is a sequence of non-zero (\0) ASCII characters with no other - formatting included by the library. - -

-

- - - - - - - - - - - - - -
- Name Message -
bytebytebytebyte

Name

-
- -

-

- - - - - - - - - - -
Field NameDescription
NameA null terminated ASCII character string.
-
- -
-

Name: Object Modification Date & Time

- -

Type: 0x000E
- Length: fixed
- Status: Optional, may not be repeated. - -

Purpose and Description: The object modification date - and time is a timestamp which indicates (using ISO-8601 date and - time format) the last modification of an object. The time is - updated when any object header message changes according to the - system clock where the change was posted. - -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Modification Time Message -
bytebytebytebyte
Year
MonthDay of Month
HourMinute
SecondReserved
-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
YearThe four-digit year as an ASCII string. For example, - 1998. All fields of this message should be interpreted - as coordinated universal time (UTC)
MonthThe month number as a two digit ASCII string where - January is 01 and December is 12.
Day of MonthThe day number within the month as a two digit ASCII - string. The first day of the month is 01.
HourThe hour of the day as a two digit ASCII string where - midnight is 00 and 11:00pm is 23.
MinuteThe minute of the hour as a two digit ASCII string where - the first minute of the hour is 00 and - the last is 59.
SecondThe second of the minute as a two digit ASCII string - where the first second of the minute is 00 - and the last is 59.
ReservedThis field is reserved and should always be zero.
-
- -
-

Name: Shared Object Message

- Type: 0x000F
- Length: 4 Bytes
- Status: Optional, may be repeated. - -

A constant message can be shared among several object headers - by writing that message in the global heap and having the object - headers all point to it. The pointing is accomplished with a - Shared Object message which is understood directly by the object - header layer of the library. It is also possible to have a - message of one object header point to a message in some other - object header, but care must be exercised to prevent cycles. - -

If a message is shared, then the message appears in the global - heap and its message ID appears in the Header Message Type - field of the object header. Also, the Flags field in the object - header for that message will have bit two set (the - H5O_FLAG_SHARED bit). The message body in the - object header will be that of a Shared Object message defined - here and not that of the pointed-to message. - -

-

- - - - - - - - - - - - - - - - - - - -
- Shared Message Message -
byte - byte - byte - byte -
VersionFlagsReserved
Reserved

Pointer

-
- -

-

- - - - - - - - - - - - - - - - - - - -
Field NameDescription
VersionThe version number for the message. This document - describes version one of shared messages.
FlagsThe Shared Message message points to a message which is - shared among multiple object headers. The Flags field - describes the type of sharing: - -
-
Bit 0 -
If this bit is clear then the actual message is the - first message in some other object header; otherwise - the actual message is stored in the global heap. - -
Bits 2-7 -
Reserved (always zero) -
-
PointerThis field points to the actual message. The format of - the pointer depends on the value of the Flags field. If - the actual message is in the global heap then the pointer - is the file address of the global heap collection that - holds the message, and a four-byte index into that - collection. Otherwise the pointer is a group entry - that points to some other object header.
-
- - -
-

Name: Object Header Continuation

-Type: 0x0010
-Length: fixed
-Status: Optional, may be repeated.
-Purpose and Description: The object header continuation is the location -in the file of more header messages for the current data object. This can be -used when header blocks are large, or likely to change over time.
-Format of Data:

- The object header continuation is formatted as follows (assuming a 4-byte -length & offset are being used in the current file): - -

-

- - - - - - - - - - - - - -
-HDF5 Object Header Continuation Message Layout -
bytebytebytebyte
Header Continuation Offset
Header Continuation Length
-
- -

-

-
The elements of the Header Continuation Message are described below: -
-
-
Header Continuation Offset: (<offset> bytes) -
This value is the offset in bytes from the beginning of the file where the -header continuation information is located. -
Header Continuation Length: (<length> bytes) -
This value is the length in bytes of the header continuation information in -the file. -
-
- - - -
-

Name: Group Message

-Type: 0x0011
-Length: fixed
-Status: Required for groups, may not be repeated.
-Purpose and Description: Each group has a B-tree and a -name heap which are pointed to by this message.
-Format of data: -

The group message is formatted as follows: - -

-

- - - - - - - - - - - - - - -
-HDF5 Object Header Group Message Layout -
bytebytebytebyte
B-tree Address
Heap Address
-
- -

-

-
The elements of the Group Message are described below: -
-
-
B-tree Address (<offset> bytes) -
This value is the offset in bytes from the beginning of the file -where the B-tree is located. -
Heap Address (<offset> bytes) -
This value is the offset in bytes from the beginning of the file -where the group name heap is located. -
-
- -

Disk Format: Level 2b - Shared Data Object Headers

-

In order to share header messages between several dataset objects, object -header messages may be placed into the global heap. Since these -messages require additional information beyond the basic object header message -information, the format of the shared message is detailed below. - -

-

- - - - - - - - - - - - - -
-HDF5 Shared Object Header Message -
bytebytebytebyte
Reference Count of Shared Header Message

Shared Object Header Message

-
- -

-

-
The elements of the shared object header message are described below: -
-
-
Reference Count of Shared Header Message: (32-bit unsigned integer) -
This value is used to keep a count of the number of dataset objects which -refer to this message from their dataset headers. When this count reaches zero, -the shared message header may be removed from the global heap. -
Shared Object Header Message: (various lengths) -
The data stored for the shared object header message is formatted in the -same way as the private object header messages described in the object header -description earlier in this document and begins with the header message Type. -
-
- - -

Disk Format: Level 2c - Data Object Data Storage

-

The data for an object is stored separately from the header -information in the file and may not actually be located in the HDF5 file -itself if the header indicates that the data is stored externally. The -information for each record in the object is stored according to the -dimensionality of the object (indicated in the dimensionality header message). -Multi-dimensional data is stored in C order [same as current scheme], i.e. the -"last" dimension changes fastest. -

Data whose elements are composed of simple number-types are stored in -native-endian IEEE format, unless they are specifically defined as being stored -in a different machine format with the architecture-type information from the -number-type header message. This means that each architecture will need to -[potentially] byte-swap data values into the internal representation for that -particular machine. -

Data with a "variable" sized number-type is stored in a data heap -internal to the HDF5 file. Global heap identifiers are stored in the -data object storage. -

Data whose elements are composed of pointer number-types are stored in several -different ways depending on the particular pointer type involved. Simple -pointers are just stored as the dataset offset of the object being pointed to with the -size of the pointer being the same number of bytes as offsets in the file. -Partial-object pointers are stored as a heap-ID which points to the following -information within the file-heap: an offset of the object pointed to, number-type -information (same format as header message), dimensionality information (same -format as header message), sub-set start and end information (i.e. a coordinate -location for each), and field start and end names (i.e. a [pointer to the] -string indicating the first field included and a [pointer to the] string name -for the last field). - -

Data of a compound datatype is stored as a contiguous stream of the items -in the structure, with each item formatted according to its datatype. - -

- - diff --git a/doxygen/examples/H5.format.1.1.html b/doxygen/examples/H5.format.1.1.html deleted file mode 100644 index 418afd5ab88..00000000000 --- a/doxygen/examples/H5.format.1.1.html +++ /dev/null @@ -1,6440 +0,0 @@ - - - - HDF5 File Format Specification Version 1.1 - - - - - -
-
- - - -
-
    -
  1. Introduction -
  2. Disk Format Level 0 - File Metadata - -
      -
    1. Disk Format Level 0A - File Signature and Super Block -
    2. Disk Format Level 0B - File Driver Info -
    -     -
  3. Disk Format Level 1 - File Infrastructure - -
      -
    1. Disk Format Level 1A - B-link Trees and B-tree Nodes -
    2. Disk Format Level 1B - Group -
    3. Disk Format Level 1C - Group Entry -
    4. Disk Format Level 1D - Local Heaps -
    5. Disk Format Level 1E - Global Heap -
    6. Disk Format Level 1F - Free-space Index -
    -     -
  4. Disk Format Level 2 - Data Objects - -
      -
    1. Disk Format Level 2a - Data Object Headers -
        -
      1. Name: NIL -
      2. Name: Simple Dataspace - -
      3. Name: Reserved - not assigned yet -
      4. Name: Datatype -
      5. Name: Data Storage - Fill Value (Old) -
      6. Name: Data Storage - Fill Value -
      -
    -     -
- 		   -
    - -
  1. Disk Format Level 2 - Data Objects - (Continued) -
      -
    1. Disk Format Level 2a - Data Object Headers(Continued) -
        - -
      1. Name: Reserved - not assigned yet -
      2. Name: Data Storage - External Data Files -
      3. Name: Data Storage - Layout -
      4. Name: Reserved - not assigned yet -
      5. Name: Reserved - not assigned yet -
      6. Name: Data Storage - Filter Pipeline -
      7. Name: Attribute -
      8. Name: Object Comment -
      9. Name: Object Modification Date and Time (Old) -
      10. Name: Shared Object Message -
      11. Name: Object Header Continuation -
      12. Name: Group Message -
      13. Name: Object Modification Date and Time -
      -
    2. Disk Format: Level 2b - Data Object Data Storage -
    -     -
  2. Appendix -
-
-
- -
-
- - -

Introduction

- - - - - - - -
  -
- HDF5 Groups - 		 
  - Figure 1: Relationships among the HDF5 root group, other groups, and objects -
- 		 
  - HDF5 Objects -  
  - Figure 2: HDF5 objects -- datasets, datatypes, or dataspaces -
- 		 
- - -

The format of an HDF5 file on disk encompasses several - key ideas of the HDF4 and AIO file formats as well as - addressing some shortcomings therein. The new format is - more self-describing than the HDF4 format and is more - uniformly applied to data objects in the file. - -

An HDF5 file appears to the user as a directed graph. - The nodes of this graph are the higher-level HDF5 objects - that are exposed by the HDF5 APIs: - -

- -

At the lowest level, as information is actually written to the disk, - an HDF5 file is made up of the following objects: -

- -

The HDF5 library uses these low-level objects to represent the - higher-level objects that are then presented to the user or - to applications through the APIs. - For instance, a group is an object header that contains a message that - points to a local heap and to a B-tree which points to symbol nodes. - A dataset is an object header that contains messages that describe - datatype, space, layout, filters, external files, fill value, etc - with the layout message pointing to either a raw data chunk or to a - B-tree that points to raw data chunks. - - -

This Document

- -

This document describes the lower-level data objects; - the higher-level objects and their properties are described - in the HDF5 User Guide. - -

Three levels of information comprise the file format. - Level 0 contains basic information for identifying and - defining information about the file. Level 1 information contains - the information about the pieces of a file shared by many objects - in the file (such as a B-trees and heaps). Level 2 is the rest - of the file and contains all of the data objects, with each object - partitioned into header information, also known as - metadata, and data. - -

The sizes of various fields in the following layout tables are - determined by looking at the number of columns the field spans - in the table. There are three exceptions: (1) The size may be - overridden by specifying a size in parentheses, (2) the size of - addresses is determined by the Size of Offsets field - in the super block and is indicated in this document with a - superscripted 'O', and (3) the size of length fields is determined - by the Size of Lengths field in the super block and is - indicated in this document with a superscripted 'L'. - -

Values for all fields in this document should be treated as unsigned - integers, unless otherwise noted in the description of a field. - Additionally, all metadata fields are stored in little-endian byte - order. -

- -
-
- -

- Disk Format: Level 0 - File Metadata

- -

- Disk Format: Level 0A - File Signature and Super Block

- -

The super block may begin at certain predefined offsets within - the HDF5 file, allowing a block of unspecified content for - users to place additional information at the beginning (and - end) of the HDF5 file without limiting the HDF5 library's - ability to manage the objects within the file itself. This - feature was designed to accommodate wrapping an HDF5 file in - another file format or adding descriptive information to the - file without requiring the modification of the actual file's - information. The super block is located by searching for the - HDF5 file signature at byte offset 0, byte offset 512 and at - successive locations in the file, each a multiple of two of - the previous location, i.e. 0, 512, 1024, 2048, etc. - -

The super block is composed of a file signature, followed by - super block and group version numbers, information - about the sizes of offset and length values used to describe - items within the file, the size of each group page, - and a group entry for the root object in the file. - -
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- HDF5 Super Block Layout -
bytebytebytebyte

HDF5 File Signature (8 bytes)

Version # of Super BlockVersion # of Global Free-space StorageVersion # of Root Group Symbol Table EntryReserved (zero)
Version # of Shared Header Message FormatSize of OffsetsSize of LengthsReserved (zero)
Group Leaf Node KGroup Internal Node K
File Consistency Flags
Indexed Storage Internal Node K1Reserved (zero)1
Base AddressO
Address of Global Free-space HeapO
End of File AddressO
Driver Information Block AddressO
Root Group Symbol Table Entry
- - - - -
- (Items marked with an 'O' the above table are -
- of the size specified in "Size of Offsets.") -
- (Items marked with an '1' the above table are -
- new in version 1 of the superblock) -
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
HDF5 File 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: -

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Decimal:13772687013102610
Hexadecimal:894844460d0a1a0a
ASCII C Notation:\211HDF\r\n\032\n
-
-
- -

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 Super Block -

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

- -

Values of 0 and 1 are defined for this field. -

- -

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

-
Version Number of the File Free-space Information -

This value is used to determine the format of the - information in the File Free-space Information. -

-

The only value currently valid in this field is '0', which - indicates that the free space index is formatted as described - below. -

- -

This field is present in version 0+ 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+ 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+ 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 super block 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+ 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+ of the superblock. -

-
File Consistency Flags -

This value contains flags to indicate information - about the consistency of the information contained - within the file. Currently, the following bit flags are - defined: -

    -
  • Bit 0 set indicates that the file is opened for - write-access. -
  • Bit 1 set indicates that the file has - been verified for consistency and is guaranteed to be - consistent with the format defined in this document. -
  • Bits 2-31 are reserved for future use. -
- Bit 0 should be - set as the first action when a file is opened for write - access and should be cleared only as the final action - when closing a file. Bit 1 should be cleared during - normal access to a file and only set after the file's - consistency is guaranteed by the library or a - consistency utility. -

- -

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

-
Indexed Storage Internal Node K -

Each internal node of a indexed storage 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 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 super block 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 -

Free-space management is not yet defined in the HDF5 - file format and is not handled by the library. - Currently this field always contains the - undefined address. -

- -

This field is present in version 0+ 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 accidentally 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+ 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+ of the superblock. -

-
-
- -

- Disk Format: Level 0B - File Driver Info

- -

The file driver information block is an optional region of the - file which contains information needed by the file driver in - order to reopen a file. The format of the file driver information - block is: - -
-

- - - - - - - - - - - - - - - - - - - - - - - - - - -
- Driver Information Block -
bytebytebytebyte
VersionReserved (zero)
Driver Information Size (4 bytes)

Driver Identification (8 bytes)



Driver Information (n bytes)


-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Version -

The version number of the driver information block. The - file format documented here is version zero. -

-
Driver Information Size -

The size in bytes of the Driver Information part of this - structure. -

-
Driver Identification -

This is an eight-byte ASCII string without null - termination which identifies the driver and version number - of the Driver Information block. The predefined drivers - supplied with the HDF5 library are 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. -

-

- For example, the various versions of the multi driver - will be identified by NCSAmult. - (NCSAmult is simply NCSAmulti truncated - to eight characters. Subsequent identifiers will be created by - substituting sequential numerical values for the final character, - starting with zero.) multi driver is the only default driver that - is encoded in this field. -

-

- Identification for user-defined drivers - is eight-byte long and arbitrary but should be unique and avoid - the four character prefix "NCSA". -

-
Driver InformationDriver information is encoded/decoded in a format defined by the - file driver. multi driver is the only default driver that has driver - information stored in this field. Its format is explained in the - following block.
-
- -
-

Multi driver has the following format:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Multi Driver Message -
bytebytebytebyte
Member MappingMember MappingMember MappingMember Mapping
Member MappingMember MappingReservedReserved

Address of Member File 1


End of Address for Member File 1


Address of Member File 2


End of Address for Member File 2


... ...


Name of Member File 1


Name of Member File 2


... ...

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Member Mapping

Multi driver enables different types of HDF5 data and - metadata to be written to separate files. These files are viewed by the - library as a single virtual HDF5 file with a single file address. - It allows maximal 6 files to be created. - In sequence, these Member Mapping fields are for super block, - B-tree, raw data, global heap, local heap, - and object header. More than one type of data can be written to the - same file.

-

These Member Mapping fields are integer values from 1 to 6 - indicating how the data can be mapped to or merged with another type of - data. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Member MappingDescription
1The super block data.
2The B-tree data.
3The raw data.
4The global heap data.
5The local heap data.
6The 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, one for super block, - B-tree, global heap, local heap, and object header. -
Reserved

These fields are reserved and should always be zero.

Address of Member File

Specifies the virtual address. A normally eight-byte integer with - the value from 0 (zero) to maximal value, - at which the member file starts.

End of Address for Member File

The end of allocated address for the member file. A normally eight-byte - integer value.

Name of Member File

The null-terminated name of member file. 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 super block), b (for B-tree), r (for raw data), - g (for global heap), l (for local heap), and o (for - object header). The name for the whole HDF5 file will substitute the %s - in the string. -

-
-
- -
-
- -

- Disk Format: Level 1 - File Infrastructure

-

Disk Format: Level 1A - B-link Trees and B-tree Nodes

- -

B-link trees allow flexible storage for objects which tend to grow - in ways that cause the object to be stored discontiguously. B-trees - are described in various algorithms books including "Introduction to - Algorithms" by Thomas H. Cormen, Charles E. Leiserson, and Ronald - L. Rivest. The B-link tree, in which the sibling nodes at a - particular level in the tree are stored in a doubly-linked list, - is described in the "Efficient Locking for Concurrent Operations - on B-trees" paper by Phillip Lehman and S. Bing Yao as published - in the ACM Transactions on Database Systems, Vol. 6, - No. 4, December 1981. - -

The B-link trees implemented by the file format contain one more - key than the number of children. In other words, each child - pointer out of a B-tree node has a left key and a right key. - The pointers out of internal nodes point to sub-trees while - the pointers out of leaf nodes point to symbol nodes and - raw data chunks. - Aside from that difference, internal nodes and leaf nodes - are identical. - -
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- B-tree Nodes -
bytebytebytebyte
Signature
Node TypeNode LevelEntries Used
Address of Left SiblingO
Address of Right SiblingO
Key 0 (variable size)
Address of Child 0O
Key 1 (variable size)
Address of Child 1O
...
Key 2K (variable size)
Address of Child 2KO
Key 2K+1 (variable size)
- - - -
- (Items marked with an 'O' the above table are -
- of the size specified in "Size of Offsets.") -
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Signature -

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

-
Node Type -

Each B-link 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 TypeDescription
0This tree points to group nodes.
1This 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-link 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 bitfield 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 it's index is set.
N 64-bit fields:A 64-bit index indicating the offset of the - chunk within the dataset where N is the number - of dimensions of the dataset. For example, if - a chunk in a 3-dimensional dataset begins at the - position [5,5,5], there will be three - such 64-bit indices, each with the value of - 5.
-
-

-
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 chunk 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. -

-
-
- -

- Conceptually, each B-tree node looks like this: -

- - - - - - - - - - - - - -
key[0] child[0] key[1] child[1] key[2] ... ... key[N-1] child[N-1] key[N]
-
-
- - where child[i] is a pointer to a sub-tree (at a level - above Level 0) or to data (at Level 0). - Each key[i] describes an item stored by the B-tree - (a chunk or an object of a group node). The range of values - represented by child[i] is indicated by key[i] - and key[i+1]. - - -

The following question must next be answered: - "Is the value described by key[i] contained in - child[i-1] or in child[i]?" - The answer depends on the type of tree. - In trees for groups (node type 0) the object described by - key[i] is the greatest object contained in - child[i-1] while in chunk trees (node type 1) the - chunk described by key[i] is the least chunk in - child[i]. - -

That means that key[0] for group trees is sometimes unused; - it points to offset zero in the heap, which is always the - empty string and compares as "less-than" any valid object name. - -

And key[N] for chunk trees is sometimes unused; - it contains a chunk offset which compares as "greater-than" - any other chunk offset and has a chunk byte size of zero - to indicate that it is not actually allocated. - - -

Disk Format: Level 1B - Group and Symbol Nodes

- -

A group is an object internal to the file that allows - arbitrary nesting of objects within the file (including other groups). - A group maps a set of names in the group to a set of relative - file addresses where objects with those names are located in - the file. Certain metadata for an object to which the group points - can be cached in the group's symbol table in addition to the - object's header. - -

An HDF5 object name space can be stored hierarchically by - partitioning the name into components and storing each - component in a group. The group entry for a - non-ultimate component points to the group containing - the next component. The group entry for the last - component points to the object being named. - -

A group is a collection of group nodes pointed - to by a B-link tree. Each group node contains entries - for one or more symbols. If an attempt is made to add a - symbol to an already full group node containing - 2K entries, then the node is split and one node - contains K symbols and the other contains - K+1 symbols. - -
-

- - - - - - - - - - - - - - - - - - - -
- Group Node (A Leaf of a B-tree) -
bytebytebytebyte
Signature
Version NumberReserved (0)Number of Symbols


Group Entries


-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Signature -

The ASCII character string "SNOD" is - used to indicate the - beginning of a group node. This gives file - consistency checking utilities a better chance of - reconstructing a damaged file. -

-
Version Number -

The version number for the group node. This - document describes version 1. (There is no version '0' - of the group node) -

-
Number of Symbols -

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

-
Group Entries -

Each symbol has an entry in the group 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 - super block. -

-
-
- -

- Disk Format: Level 1C - Group Entry

- -

Each group entry in a group node is designed - to allow for very fast browsing of stored objects. - Toward that design goal, the group entries - include space for caching certain constant metadata from the - object header. - -
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Group Entry -
bytebytebytebyte
Name OffsetO
Object Header AddressO
Cache Type
Reserved


Scratch-pad Space (16 bytes)


- - - -
- (Items marked with an 'O' the above table are -
- of the size specified in "Size of Offsets.") -
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Name Offset -

This is the byte offset into the group local - heap for the name of the object. 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 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:
0No 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. -
1Object header metadata is cached in the group - entry. This implies that the group - entry refers to another group. -
2The 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. -
NOther cache values can be defined later and - libraries that do not understand the new values will - still work properly. -
-

-
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 a dataset object represented in the scratch-pad - space is duplicated in the object header for that - dataset. This metadata can include the datatype - and the size of the dataspace for a dataset whose datatype - is atomic and whose dataspace is fixed and less than - four dimensions. -

-

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

-
-
- -

Format of the Scratch-pad Space

- -

The group entry scratch-pad space is formatted - according to the value in the Cache Type field. - -

If the Cache Type field contains the value zero - (0) then no information is - stored in the scratch-pad space. - -

If the Cache Type field contains the value one - (1), then the scratch-pad space - contains cached metadata for another object header - in the following format: - -
-

- - - - - - - - - - - - - - -
- Object Header Scratch-pad Format -
bytebytebytebyte
Address of B-treeO
Address of Name HeapO
- - - -
- (Items marked with an 'O' the above table are -
- of the size specified in "Size of Offsets.") -
-
- -
-
- - - - - - - - - - - - - - - -
Field NameDescription
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. -

-
-
- - -

If the Cache Type field contains the value two - (2), then the scratch-pad space - contains cached metadata for another symbolic link - in the following format: - -
-

- - - - - - - - - - - - - -
- Symbolic Link Scratch-pad Format -
bytebytebytebyte
Offset to Link Value
-
- -
-
- - - - - - - - - - -
Field NameDescription
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. -

-
-
- -

Disk Format: Level 1D - Local Heaps

- -

A heap is a collection of small heap objects. Objects can be - inserted and removed from the heap at any time. - The address of a heap does not change once the heap is created. - References to objects are stored in the group table; - the names of those objects are stored in the local heap. -

- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Local Heap -
bytebytebytebyte
Signature
VersionReserved (zero)
Data Segment SizeL
Offset to Head of Free-listL
Address of Data SegmentO
- - - - -
- (Items marked with an 'L' the above table are -
- of the size specified in "Size of Lengths.") -
- (Items marked with an 'O' the above table are -
- of the size specified in "Size of Offsets.") -
-
- -

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
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 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. -

-
-
- -

Objects within the heap should be aligned on an 8-byte boundary. - -

Disk Format: Level 1E - Global Heap

- -

Each HDF5 file has a global heap which stores various types of - information which is typically shared between datasets. The - global heap was designed to satisfy these goals: - -

    -
  1. Repeated access to a heap object must be efficient without - resulting in repeated file I/O requests. Since global heap - objects will typically be shared among several datasets, it is - probable that the object will be accessed repeatedly. -
  2. Collections of related global heap objects should result in - fewer and larger I/O requests. For instance, a dataset of - object references will have a global heap object for each - reference. Reading the entire set of object references - should result in a few large I/O requests instead of one small - I/O request for each reference. -
  3. It should be possible to remove objects from the global heap - and the resulting file hole should be eligible to be reclaimed - for other uses. -
-

- -

The implementation of the heap makes use of the memory - management already available at the file level and combines that - with a new top-level object called a collection to - achieve Goal B. The global heap is the set of all collections. - Each global heap object belongs to exactly one collection and - each collection contains one or more global heap objects. For - the purposes of disk I/O and caching, a collection is treated as - an atomic object. -

- -

The HDF5 library creates global heap collections as needed, so there may - be multiple collections throughout the file. The set of all of them is - abstractly called the "global heap", although they don't actually link - to each other, and there is no global place in the file where you can - discover all of the collections. The collections are found simply by - finding a reference to one through another object in the file (eg. - variable-length datatype elements, etc). -

- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- A Global Heap Collection -
bytebytebytebyte
Signature
VersionReserved (zero)
Collection SizeL

Global Heap Object 1


Global Heap Object 2


...


Global Heap Object N


Global Heap Object 0 (free space)

- - - -
- (Items marked with an 'L' the above table are -
- of the size specified in "Size of Lengths.") -
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
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 the - collection contains no free space. -

-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
- Global Heap Object -
bytebytebytebyte
Heap Object IDReference Count
Reserved
Object SizeL

Object Data

- - - -
- (Items marked with an 'L' the above table are -
- of the size specified in "Size of Lengths.") -
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Heap Object ID -

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. -

-
-
- -

Disk Format: Level 1F - Free-space Index

- -

The free-space index is a collection of blocks of data, - dispersed throughout the file, which are currently not used by - any file objects. - -

The super block contains a pointer to root of the free-space description; - that pointer is currently required to be the - undefined address. - -

The format of the free-space index is not defined at this time. - - - -
-

- -

Disk Format: Level 2 - Data Objects

- -

Data objects contain the real information in the file. These - objects compose the scientific data and other information which - are generally thought of as "data" by the end-user. All the - other information in the file is provided as a framework for - these data objects. -

- -

A data object is composed of header information and data - information. The header information contains the information - needed to interpret the data information for the data object as - well as additional "metadata" or pointers to additional - "metadata" used to describe or annotate each data object. -

- -

- Disk Format: Level 2A - Data Object Headers

- -

The header information of an object is designed to encompass - all the information about an object, except for the data itself. - This information includes - the dataspace, datatype, information about how the data - is stored on disk (in external files, compressed, broken up in - blocks, etc.), as well as other information used by the library - to speed up access to the data objects or maintain a file's - integrity. Information stored by user applications as attributes - is also stored in the object's header. The header of each object is - not necessarily located immediately prior to the object's data in the - file and in fact may be located in any position in the file. The order - of the messages in an object header is not significant. -

- -

Header messages are aligned on 8-byte boundaries. -

- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Object Headers -
bytebytebytebyte
VersionReserved (zero)Number of Header Messages
Object Reference Count
Object Header Size
Header Message Type #1Size of Header Message Data #1
Header Message #1 FlagsReserved (zero)

Header Message Data #1

.
.
.
Header Message Type #nSize of Header Message Data #n
Header Message #n FlagsReserved (zero)

Header Message Data #n

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Version -

This value is used to determine the format of the - information in the object header. When the format of the - information in 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 - document describes version one (1) (there was no version - zero (0)). -

-
Number of Header Messages -

This value determines the 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 Type -

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

-
Size of Header Message 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 Flags -

This is a bit field with the following definition: - - - - - - - - - - - - - - - - - - -
BitDescription
0If set, the message data is constant. This is used - for messages like the datatype message of a dataset. -
1If set, the message is stored in the global heap. - The Header Message Data field contains a Shared Object - message and the Size of Header Message Data field - contains the size of that Shared Object message. -
2-7Reserved
-

-
Header Message 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 zeros to make the - size a multiple of eight. -

-
-
- -

The header message types and the message data associated with - them compose the critical "metadata" about each object. Some - header messages are required for each object while others are - optional. Some optional header messages may also be repeated - several times in the header itself, the requirements and number - of times allowed in the header will be noted in each header - message description below. -

- -

The following is a list of currently defined header messages: -

- -
-

Name: NIL

- -

Header Message Type: 0x0000 -

-

Length: varies -

-

Status: Optional, may be repeated. -

-

Purpose and Description: The NIL message is used to indicate a - message which is to be ignored when reading the header messages for a - data object. [Possibly one which has been deleted for some reason.] -

-

Format of Data: Unspecified. -

- -
-

Name: Simple Dataspace

- -

Header Message Type: 0x0001 -

-

Length: Varies according to the number of dimensions, - as described in the following table. -

-

Status: Required for dataset objects, may not be - repeated. -

-

Description: The simple dataspace message describes the - number of dimensions (i.e. "rank") and size of each dimension that the - data object has. This message is only used for datasets which have a - simple, rectilinear grid layout; datasets requiring a more complex - layout (irregularly structured or unstructured grids, etc.) must use - the Complex Dataspace message for expressing the space the - dataset inhabits. (Note: The Complex Dataspace - functionality is not yet implemented and it is not described in this - document.) -

- -

Format of Data: -
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Simple Dataspace Message -
bytebytebytebyte
VersionDimensionalityFlagsReserved
Reserved
Dimension #1 SizeL
.
.
.
Dimension #n SizeL
Dimension #1 Maximum SizeL
.
.
.
Dimension #n Maximum SizeL
Permutation Index #1L
.
.
.
Permutation Index #nL
- - - -
- (Items marked with an 'L' the above table are -
- of the size specified in "Size of Lengths.") -
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Version -

This value is used to determine the format of the - Simple 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. -

-
-
- -

- - - -
-

Name: Reserved - Not Assigned Yet

- Header Message Type: 0x0002
- Length: N/A
- Status: N/A
- Format of Data: N/A
- -

Purpose and Description: This message type was skipped during - the initial specification of the file format and may be used in a - future expansion to the format. - - -

-

Name: Datatype

- -

Header Message Type: 0x0003 -

-

Length: variable -

-

Status: Required for dataset or named datatype objects, - may not be repeated. -

- -

Description: The datatype message defines the datatype - for each element of a dataset. A datatype can describe an atomic type - like a fixed- or floating-point type or a compound type like a C - struct. - Datatypes messages are stored - as a list of datatype classes and - their associated properties. -

- -

Datatype messages that are part of a dataset object, - do not describe how elements are related to one another, the dataspace - message is used for that purpose. Datatype messages that are part of - a named datatype message describe an "abstract" datatype that can be - used by other objects in the file. -

- -

Format of Data: -
-

- - - - - - - - - - - - - - - - - - - - - - - - -
- Datatype Message -
bytebytebytebyte
Class and VersionClass Bit Field, Bits 0-7Class Bit Field, Bits 8-15Class Bit Field, Bits 16-23
Size


Properties


-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
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: - - - - - - - - - - - - - - - - - - -
VersionDescription
0Never used -
1Used by early versions of the library to encode - compound datatypes with explicit array fields. - See the compound datatype description below for - further details. -
2The current version used by the library. -
-

-

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: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Fixed-Point
1Floating-Point
2Time
3String
4Bitfield
5Opaque
6Compound
7Reference
8Enumerated
9Variable-Length
10Array
-

-
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 the datatype in bytes. -

-
Properties -

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

-
-
-

- -

Class specific information for Fixed-Point Numbers (Class 0): - -
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Bit Field Description -
BitsMeaning
0Byte Order. If zero, byte order is little-endian; - otherwise, byte order is big endian.
1, 2Padding type. Bit 1 is the lo_pad type and bit 2 - is the hi_pad type. If a datum has unused bits at either - end, then the lo_pad or hi_pad bit is copied to those - locations.
3Signed. If this bit is set then the fixed-point - number is in 2's complement form.
4-23Reserved (zero).
-
- -
-
- - - - - - - - - - - - - - -
- Property Descriptions -
ByteByteByteByte
Bit OffsetBit Precision
-
- -
-
- - - - - - - - - - - - - - - - -
Field NameDescription
Bit Offset -

The bit offset of the first significant bit of the fixed-point - value within the datatype. The bit offset specifies the number - of bits "to the right of" the value. -

-
Bit Precision -

The number of bits of precision of the fixed-point value - within the datatype. -

-
-
-

- -

Class specific information for Floating-Point Numbers (Class 1): - -
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Bit Field Description -
BitsMeaning
0Byte Order. If zero, byte order is little-endian; - otherwise, byte order is big endian.
1, 2, 3Padding type. Bit 1 is the low bits pad type, bit 2 - is the high bits pad type, and bit 3 is the internal bits - pad type. If a datum has unused bits at either end or between - the sign bit, exponent, or mantissa, then the value of bit - 1, 2, or 3 is copied to those locations.
4-5Normalization. The value can be 0 if there is no - normalization, 1 if the most significant bit of the - mantissa is always set (except for 0.0), and 2 if the most - significant bit of the mantissa is not stored but is - implied to be set. The value 3 is reserved and will not - appear in this field.
6-7Reserved (zero).
8-15Sign Location. This is the bit position of the sign - bit. Bits are numbered with the least significant bit zero.
16-23Reserved (zero).
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
- Property Descriptions -
ByteByteByteByte
Bit OffsetBit Precision
Exponent LocationExponent SizeMantissa LocationMantissa Size
Exponent Bias
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Bit Offset -

The bit offset of the first significant bit of the floating-point - value within the datatype. The bit offset specifies the number - of bits "to the right of" the value. -

-
Bit Precision -

The number of bits of precision of the floating-point value - within the datatype. -

-
Exponent Location -

The bit position of the exponent field. Bits are numbered with - the least significant bit number zero. -

-
Exponent Size -

The size of the exponent field in bits. -

-
Mantissa Location -

The bit position of the mantissa field. Bits are numbered with - the least significant bit number zero. -

-
Mantissa Size -

The size of the mantissa field in bits. -

-
Exponent Bias -

The bias of the exponent field. -

-
-
-

- -

Class specific information for Time (Class 2): - -
-

- - - - - - - - - - - - - - - - - -
- Bit Field Description -
BitsMeaning
0Byte Order. If zero, byte order is little-endian; - otherwise, byte order is big endian.
1-23Reserved (zero).
-
- -
-
- - - - - - - - - - - -
- Property Descriptions -
ByteByte
Bit Precision
-
- -
-
- - - - - - - - - - - -
Field NameDescription
Bit Precision -

The number of bits of precision of the time value. -

-
-
-

- -

Class specific information for Strings (Class 3): - -
-

- - - - - - - - - - - - - - - - - - - - - -
- Bit Field Description -
BitsMeaning
0-3Padding type. This four-bit value determines the - type of padding to use for the string. The values are: - - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Null Terminate: A zero byte marks the end of the - string and is guaranteed to be present after - converting a long string to a short string. When - converting a short string to a long string the value is - padded with additional null characters as necessary. -
1Null Pad: Null characters are added to the end of - the value during conversions from short values to long - values but conversion in the opposite direction simply - truncates the value. -
2Space Pad: Space characters are added to the end of - the value during conversions from short values to long - values but conversion in the opposite direction simply - truncates the value. This is the Fortran - representation of the string. -
3-15Reserved -
-
4-7Character Set. The character set to use for - encoding the string. The only character set supported is - the 8-bit ASCII (zero) so no translations have been defined - yet.
8-23Reserved (zero).
-
- -

There are no properties defined for the string class. -

-

- -

Class specific information for Bitfields (Class 4): - -
-

- - - - - - - - - - - - - - - - - - - - - - -
- Bit Field Description -
BitsMeaning
0Byte Order. If zero, byte order is little-endian; - otherwise, byte order is big endian.
1, 2Padding type. Bit 1 is the lo_pad type and bit 2 - is the hi_pad type. If a datum has unused bits at either - end, then the lo_pad or hi_pad bit is copied to those - locations.
3-23Reserved (zero).
-
- -
-
- - - - - - - - - - - - - - -
- Property Description -
ByteByteByteByte
Bit OffsetBit Precision
-
- -
-
- - - - - - - - - - - - - - - -
Field NameDescription
Bit Offset -

The bit offset of the first significant bit of the bitfield - within the datatype. The bit offset specifies the number - of bits "to the right of" the value. -

-
Bit Precision -

The number of bits of precision of the bitfield - within the datatype. -

-
-
-

- -

Class specific information for Opaque (Class 5): - -
-

- - - - - - - - - - - - - - - - - -
- Bit Field Description -
BitsMeaning
0-7Length of ASCII tag in bytes.
8-23Reserved (zero).
-
- -
-
- - - - - - - - - - - - - -
- Property Description -
ByteByteByteByte

ASCII Tag
-
-
- -
-
- - - - - - - - - - -
Field NameDescription
ASCII Tag -

This NUL-terminated string provides a description for the - opaque type. It is NUL-padded to a multiple of 8 bytes. -

-
-
-

- -

Class specific information for Compound (Class 6): - -
-

- - - - - - - - - - - - - - - - -
- Bit Field Description -
BitsMeaning
0-15Number of Members. This field contains the number - of members defined for the compound datatype. The member - definitions are listed in the Properties field of the data - type message. -
15-23Reserved (zero).
-
-

- -

The Properties field of a compound datatype is a list of the - member definitions of the compound datatype. The member - definitions appear one after another with no intervening bytes. - The member types are described with a recursive datatype - message. - -

Note that the property descriptions are different for different - versions of the datatype version. Additionally note that the version - 0 properties are deprecated and have been replaced with the version - 1 properties in versions of the HDF5 library from the 1.4 release - onward. - -
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Properties Description for Datatype Version 1 -
ByteByteByteByte

Name

Byte Offset of Member
DimensionalityReserved (zero)
Dimension Permutation
Reserved (zero)
Dimension #1 Size (required)
Dimension #2 Size (required)
Dimension #3 Size (required)
Dimension #4 Size (required)

Member Type Message

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Name -

This NUL-terminated string provides a description for the - opaque type. It is NUL-padded to a multiple of 8 bytes. -

-
Byte Offset of Member -

This is the byte offset of the member within the datatype. -

-
Dimensionality -

If set to zero, this field indicates a scalar member. If set - to a value greater than zero, this field indicates that the - member is an array of values. For array members, the size of - the array is indicated by the 'Size of Dimension n' field in - this message. -

-
Dimension Permutation -

This field was intended to allow an array field to have - it's dimensions permuted, but this was never implemented. - This field should always be set to zero. -

-
Dimension #n Size -

This field is the size of a dimension of the array field 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. -

-
Member Type Message -

This field is a datatype message describing the datatype of - the member. -

-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - -
- Properties Description for Datatype Version 2 -
ByteByteByteByte

Name

Byte Offset of Member

Member Type Message

-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Name -

This NUL-terminated string provides a description for the - opaque type. It is NUL-padded to a multiple of 8 bytes. -

-
Byte Offset of Member -

This is the byte offset of the member within the datatype. -

-
Member Type Message -

This field is a datatype message describing the datatype of - the member. -

-
-
-

- -

Class specific information for Reference (Class 7): - -
-

- - - - - - - - - - - - - - - - - -
- Bit Field Description -
BitsMeaning
0-3Type. This four-bit value contains the type of reference - described. The values defined are: - - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Object Reference: A reference to another object in this - HDF5 file. -
1Dataset Region Reference: A reference to a region within - a dataset in this HDF5 file. -
2Internal Reference: A reference to a region within the - current dataset. (Not currently implemented) -
3-15Reserved -
- -
15-23Reserved (zero).
-
- -

There are no properties defined for the reference class. -

-

- -

Class specific information for Enumeration (Class 8): - -
-

- - - - - - - - - - - - - - - - - -
- Bit Field Description -
BitsMeaning
0-15Number of Members. The number of name/value - pairs defined for the enumeration type.
16-23Reserved (zero).
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - -
- Property Description -
ByteByteByteByte

Base Type


Names


Values

-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Base Type -

Each enumeration type is based on some parent type, usually an - integer. The information for that parent type is described - recursively by this field. -

-
Names -

The name for each name/value pair. Each name is stored as a null - terminated ASCII string in a multiple of eight bytes. The names - are in no particular order. -

-
Values -

The list of values in the same order as the names. The values - are packed (no inter-value padding) and the size of each value - is determined by the parent type. -

-
-
-

- - -

Class specific information for Variable-Length (Class 9): - -
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Bit Field Description -
BitsMeaning
0-3Type. This four-bit value contains the type of - variable-length datatype described. The values defined are: - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Sequence: A variable-length sequence of any sequence of - data. Variable-length sequences do not have padding or - character set information. -
1String: A variable-length sequence of characters. - Variable-length strings have padding and character set - information. -
2-15Reserved -
- -
4-7Padding type. (variable-length string only) - This four-bit value determines the type of padding - used for variable-length strings. The values are the same - as for the string padding type, as follows: - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Null terminate: A zero byte marks the end of a string - and is guaranteed to be present after converting a long - string to a short string. When converting a short string - to a long string, the value is padded with additional null - characters as necessary. -
1Null pad: Null characters are added to the end of the - value during conversion from a short string to a longer - string. Conversion from a long string to a shorter string - simply truncates the value. -
2Space pad: Space characters are added to the end of the - value during conversion from a short string to a longer - string. Conversion from a long string to a shorter string - simply truncates the value. This is the Fortran - representation of the string. -
3-15Reserved -
- - This value is set to zero for variable-length sequences. - -
8-11Character Set. (variable-length string only) - This four-bit value specifies the character set - to be used for encoding the string: - - - - - - - - - - - - - - - -
ValueDescription
0ASCII: As of this writing (July 2003, Release 1.6.0), - 8-bit ASCII is the only character set supported. Therefore, - no translations have been defined. -
1-15Reserved -
- - This value is set to zero for variable-length sequences. - -
12-23Reserved (zero).
-
- -
-
- - - - - - - - - - - - - - -
- Property Description -
ByteByteByteByte

Base Type

-
- -
-
- - - - - - - - - - - -
Field NameDescription
Base Type -

Each variable-length type is based on some parent type. The - information for that parent type is described recursively by - this field. -

-
-
-

- -

Class specific information for Array (Class 10): - -

There are no bit fields defined for the array class. -

- -

Note that the dimension information defined in the property for this - datatype class is independent of dataspace information for a dataset. - The dimension information here describes the dimensionality of the - information within a data element (or a component of an element, if the - array datatype is nested within another datatype) and the dataspace for a - dataset describes the location of the elements in a dataset. -

- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Property Description -
ByteByteByteByte
DimensionalityReserved (zero)
Dimension #1 Size
.
.
.
Dimension #n Size
Permutation Index #1
.
.
.
Permutation Index #n

Base Type

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Dimensionality -

This value is the number of dimensions that the array has. -

-
Dimension #n Size -

This value is the size of the dimension of the array - 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. -

-
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. Currently, dimension - permutations are not supported and these indices should be set - to the index position minus one (i.e. the first dimension should - be set to 0, the second dimension should be set to 1, etc.) -

-
Base Type -

Each array type is based on some parent type. The - information for that parent type is described recursively by - this field. -

-
-
- -

- -
-

Name: Data Storage - Fill Value (Old)

- -

Header Message Type: 0x0004 -

-

Length: varies -

-

Status: Optional, may not be repeated. -

- -

Description: The fill value message stores a single - data value which is returned to the application when an uninitialized - data element is read from a dataset. The fill value is interpreted - with the same datatype as the dataset. If no fill value message is - present then a fill value of all zero bytes is assumed. -

- -

This fill value message is deprecated in favor of the "new" - fill value message (Message Type 0x0005) and is only written to the - file for forward compatibility with versions of the HDF5 library before - the 1.6.0 version. Additionally, it only appears for datasets with a - user defined fill value (as opposed to the library default fill value - or an explicitly set "undefined" fill value). -

- -

Format of Data: -
-

- - - - - - - - - - - - - - - - - -
- Fill Value Message (Old) -
bytebytebytebyte
Size

Fill Value

-
- -
-
- - - - - - - - - - - - - - - -
Field NameDescription
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. -

-
-
-

- -
-

Name: Data Storage - Fill Value

- -

Header Message Type: 0x0005 -

-

Length: varies -

-

Status: Required for dataset objects, may not be repeated. -

- -

Description: The fill value message stores a single - data value which is returned to the application when an uninitialized - data element is read from a dataset. The fill value is interpreted - with the same datatype as the dataset. -

- -

Format of Data: -
-

- - - - - - - - - - - - - - - - - - - - - - - - -
- Fill Value Message -
bytebytebytebyte
VersionSpace Allocation TimeFill Value Write TimeFill Value Defined
Size

Fill Value

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Version -

The version number information is used for changes in the - format of the fill value message and is described here: - - - - - - - - - - - - - - - - - - -
VersionDescription
0Never used -
1Used by version 1.6.x of the library to encode - fill values. In this version, the Size field is - always present. -
2The current version used by the library (version - 1.7.3 or later). In this version, the Size and - Fill Value fields are - only present if the Fill Value Defined field is set - to 1. -
-

-
Space Allocation Time -

When the storage space for the dataset's raw data will be - allocated. The allowed values are: - - - - - - - - - - - - - - - - - - -
ValueDescription
1Early allocation. Storage space for the entire dataset - should be allocated in the file when the dataset is - created. -
2Late allocation. Storage space for the entire dataset - should not be allocated until the dataset is written - to. -
3Incremental 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: - - - - - - - - - - - - - - - - - - -
ValueDescription
0On allocation. The fill value is always written to - the raw data storage when the storage space is allocated. -
1Never. The fill value should never be written to - the raw data storage. -
2Fill 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 field. -

-
Size -

This is the size of the Fill Value field in bytes. This field - is not present if the Version field is >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 >1 and the Fill Value - Defined field is set to 0. -

-
-
-

- - - -
-

Name: Reserved - Not Assigned Yet

-

Header Message Type: 0x0006

-

Length: N/A

-

Status: N/A

-

Format of Data: N/A

- -

Purpose and Description: This message type was skipped during - the initial specification of the file format and may be used in a - future expansion to the format.

- -
-

Name: Data Storage - - External Data Files

-

Header Message Type: 0x0007

-

Length: varies

-

Status: Optional, may not be repeated.

- -

Purpose and Description: The external object message - indicates that the data for an object is stored outside the HDF5 - file. The filename of the object is stored as a Universal - Resource Location (URL) of the actual filename containing the - data. An external file list record also contains the byte offset - of the start of the data within the file and the amount of space - reserved in the file for that data.

- -

Format of Data: -
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- External File List Message -
bytebytebytebyte
VersionReserved
Allocated SlotsUsed Slots

Heap Address


Slot Definitions...

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Version -

The version number information is used for changes in the format of External File - List Message and is described here: - - - - - - - - - - - -
VersionDescription
0Never used. -
1The current version used by the library. -
-

-
Reserved -

This field is reserved for future use.

-
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.

-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
- External File List Slot -
bytebytebytebyte

Name Offset(<size> bytes)


File Offset(<size> bytes)


Size

-
- -
-
- - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Name Offset(<size> bytes) -

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).

-
File Offset(<size> bytes) -

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.

-
Size -

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 zeros - past the end of the file without failing.

-
-
- - -
-

Name: Data Storage - Layout

- -

Header Message Type: 0x0008

-

Length: varies

-

Status: Required for datasets, may not be repeated.

- -

Purpose and Description: Data layout describes how the - elements of a multi-dimensional array are arranged in the linear - address space of the file. Three types of data layout are - supported: - -

    -
  1. Contiguous: The array can be stored in one contiguous area of the file. - The layout requires that the size of the array be constant and - does not permit chunking, compression, checksums, encryption, - etc. The message stores the total size of the array and the - offset of an element from the beginning of the storage area is - computed as in C. - -
  2. Chunked: The array domain can be regularly decomposed into chunks and - each chunk is allocated separately. This layout supports - arbitrary element traversals, compression, encryption, and - checksums, and the chunks can be distributed across external - raw data files (these features are described in other - messages). The message stores the size of a chunk instead of - the size of the entire array; the size of the entire array can - be calculated by traversing the B-tree that stores the chunk - addresses. - -
  3. Compact: The array can be stored in one contiguous block, as part of - this object header message (this is called "compact" storage below). -
- -

Format of Data: -
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Data Layout Message (Versions 1 and 2) -
bytebytebytebyte
VersionDimensionalityLayout ClassReserved
Reserved

Address

Dimension 0 (4-bytes)
Dimension 1 (4-bytes)
...
Dataset Element Size (optional)
Compact Data Size (4-bytes)

Compact Data...

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Version -

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

- - - - - - - - - - - - - - - - - - - - -
VersionDescription
0Never used.
1Used by version 1.4 and before of the library to encode layout information. - Data space is always allocated when the data set is created.
2Used by version 1.6.x of the library to encode layout information. - Data space is allocated only when it is necessary.
-
Dimensionality

An array has a fixed dimensionality. This field - specifies the number of dimension size fields later in the - message.

Layout Class

The layout class specifies how the other fields of the - layout message are to be interpreted. A value of one - indicates contiguous storage, a value of two indicates chunked storage, - while a value of zero indicates compact storage. Other values will be defined - in the future.

Address

For contiguous storage, this is the address of the first - byte of storage. For chunked storage this is the address - of the B-tree that is used to look up the addresses of the - chunks. This field is not present for compact storage. - If the version for this message is set to 2, the address - may have the "undefined address" value, to indicate that - storage has not yet been allocated for this array.

Dimensions

For contiguous and compact storage the dimensions define - the entire size of the array while for chunked storage they define - the size of a single chunk. In all cases, they are in units of - array elements (not bytes). The first dimension stored in the list - of dimensions is the slowest changing dimension and the last - dimension stored is the fastest changing dimension. -

-
Dataset Element Size

The size of a dataset element, in bytes. This field is only - present for chunked storage. -

-
Compact Data Size

This field is only present for compact data storage. - It contains the size of the raw data for the dataset array.

Compact Data

This field is only present for compact data storage. - It contains the raw data for the dataset array.

-
- -
-

Version 3 of this message re-structured the format into specific - properties that are required for each layout class. - -
-

- - - - - - - - - - - - - - - - - - - -
- Data Layout Message (Version 3) -
bytebytebytebyte
VersionLayout Class 

Properties

-
- -
-
- - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Version -

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

- - - - - - - - - - -
VersionDescription
3Used by the version 1.6.3 and later of the library to store properties - for each layout class.
-
Layout Class

The layout class specifies how the other fields of the layout message are to be - interpreted. A value of one indicates contiguous storage, a value of two - indicates chunked storage, while a value of zero indicates compact storage.

Properties

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

-
- -
-

Class-specific information for compact layout (Class 0): (Note: The dimensionality information - is in the Dataspace message) - -
-

- - - - - - - - - - - - - - - - - - -
- Property Descriptions -
bytebytebytebyte
Size 

Raw Data...

-
- -
-
- - - - - - - - - - - - - - - -
Field NameDescription
Size

This field contains the size of the raw data for the dataset array.

Raw Data

This field contains the raw data for the dataset array.

-
- -
-

Class-specific information for contiguous layout (Class 1): (Note: The dimensionality information - is in the Dataspace message) - -
-

- - - - - - - - - - - - - - - - - -
- Property Descriptions -
bytebytebytebyte

Address


Size

-
- -
-
- - - - - - - - - - - - - - - -
Field NameDescription
Address

This is the address of the first byte of raw data storage. - The address may have the "undefined address" value, to indicate - that storage has not yet been allocated for this array.

Size

This field contains the size allocated to store the raw data.

-
- -
-

Class-specific information for chunked layout (Class 2): - -
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Property Descriptions -
bytebytebytebyte
Dimensionality 

Address

Dimension 0 (4-bytes)
Dimension 1 (4-bytes)
...
Dataset Element Size
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Dimensionality

A chunk has a fixed dimensionality. This field specifies - the number of dimension size fields later in the message.

Address

This is the address of the B-tree that is used to look up the addresses of the - chunks. The address may have the "undefined address" value, to indicate that - storage has not yet been allocated for this array.

Dimensions

These values define the dimension size of a single chunk, in - units of array elements (not bytes). The first dimension stored in - the list of dimensions is the slowest changing dimension and the - last dimension stored is the fastest changing dimension. -

-
Dataset Element Size

The size of a dataset element, in bytes. -

-
-
- -
-

Name: Reserved - Not Assigned Yet

-

Header Message Type: 0x0009

-

Length: N/A

-

Status: N/A

-

Format of Data: N/A

- -

Purpose and Description: This message type was skipped during the initial - specification of the file format and may be used in a future expansion to the format. - -

-

Name: Reserved - Not Assigned Yet

-

Header Message Type: 0x0009

-

Length: N/A

-

Status: N/A

-

Format of Data: N/A

- -

Purpose and Description: This message type was skipped during the initial - specification of the file format and may be used in a future expansion to the format. - -

-

Name: Data Storage - Filter Pipeline

-

Header Message Type: 0x000B

-

Length: varies

-

Status: Optional, may not be repeated.

- -

Description: This message describes the - filter pipeline which should be applied to the data stream by - providing filter identification numbers, flags, a name, and - client data.

- -

Format of Data: -
-

- - - - - - - - - - - - - - - - - - - - - - - -
- Filter Pipeline Message -
bytebytebytebyte
VersionNumber of FiltersReserved
Reserved

Filter List

-
- -
-
- - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Version

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

Number of Filters

The total number of filters described by this - message. The maximum possible number of filters in a - message is 32.

Filter List

A description of each filter. A filter description - appears in the next table.

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Filter Description -
bytebytebytebyte
Filter IdentificationName Length
FlagsNumber of Values for Client Data

Name


Client Data

Padding
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Filter Identification -

- This value, often referred to as a filter identifier, - is designed to be a unique identifier for the filter. - Values from zero through 32,767 are reserved for filters - supported by The HDF Group in the HDF5 library and for - filters requested and supported by third parties. - Filters supported by The HDF Group are documented immediately - below. Information on 3rd-party filters can be found at - - https://github.com/HDFGroup/hdf5_plugins/blob/master/docs/RegisteredFilterPlugins.md. - 1 -

- To request a filter identifier, please contact - The HDF Group’s Help Desk at - . - You will be asked to provide the following information: -

    -
  1. Contact information for the developer requesting the - new identifier -
  2. A short description of the new filter -
  3. Links to any relevant information, including licensing - information -
-

- Values from 32768 to 65535 are reserved for non-distributed uses - (for example, internal company usage) or for application usage - when testing a feature. The HDF Group does not track or document - the use of the filters with identifiers from this range. - -

- The filters currently in library version 1.6.5 are - listed below: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IdentificationNameDescription
1deflateGZIP deflate compression
2shuffleData element shuffling
3fletcher32Fletcher32 checksum
4szipSZIP compression
-

Name Length

Each filter has an optional null-terminated ASCII name - and this field holds the length of the name including the - null termination padded with nulls to be a multiple of - eight. If the filter has no name then a value of zero is - stored in this field.

Flags

The flags indicate certain properties for a filter. The - bit values defined so far are:

- - - - - - - - - - -
ValueDescription
bit 1If set then the filter is an optional filter. - During output, if an optional filter fails it will be - silently removed from the pipeline.
-
Client Data Number of Values

Each filter can store a few integer values to control - how the filter operates. The number of entries in the - Client Data array is stored in this field.

Name

If the Name Length field is non-zero then it will - contain the size of this field, a multiple of eight. This - field contains a null-terminated, ASCII character - string to serve as a comment/name for the filter.

Client Data

This is an array of four-byte integers which will be - passed to the filter function. The Client Data Number of - Values determines the number of elements in the array.

Padding

Four bytes of zeros are added to the message at this - point if the Client Data Number of Values field contains - an odd number.

-
-

-

- 1If you are reading - an earlier version of this document, this link may have changed. - If the link does not work, use the latest version of this document - on The HDF Group’s website, - - H5.format.html; - the link there will always be correct. - (Return) -

- -
-

Name: Attribute

-

Header Message Type: 0x000C -

Length: varies -

Status: Optional, may be repeated. - -

Description: The Attribute - message is used to list objects in the HDF file which are used - as attributes, or "metadata" about the current object. An - attribute is a small dataset; it has a name, a datatype, a data - space, and raw data. Since attributes are stored in the object - header they must be relatively small (<64KB) and can be - associated with any type of object which has an object header - (groups, datasets, named types and spaces, etc.). - -

Note: Attributes on an object must have unique names. (The HDF5 library - currently enforces this by causing the creation of an attribute with - a duplicate name to fail). Attributes on different objects may have the - same name, however. - -

Format of Data: -
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Attribute Message (Version 1) -
bytebytebytebyte
VersionReservedName Size
Datatype SizeDataspace Size

Name


Datatype


Dataspace


Data

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Version

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

- - - - - - - - - - - - - - - -
VersionDescription
0Never used.
1Used by the library before version 1.6 to encode attribute message. - This version does not support shared data type.
-
Reserved

This field is reserved for later use and is set to - zero.

Name Size

The length of the attribute name in bytes including the - null terminator. Note that the Name field below may - contain additional padding not represented by this - field.

Datatype Size

The length of the datatype description in the Datatype - field below. Note that the Datatype field may contain - additional padding not represented by this field.

Dataspace Size

The length of the dataspace description in the Dataspace - field below. Note that the Dataspace field may contain - additional padding not represented by this field.

Name

The null-terminated attribute name. This field is - padded with additional null characters to make it a - multiple of eight bytes.

Datatype

The datatype description follows the same format as - described for the datatype object header message. This - field is padded with additional zero bytes to make it a - multiple of eight bytes.

Dataspace

The dataspace description follows the same format as - described for the dataspace object header message. This - field is padded with additional zero bytes to make it a - multiple of eight bytes.

Data

The raw data for the attribute. The size is determined - from the datatype and dataspace descriptions. This - field is not padded with additional bytes.

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Attribute Message (Version 2) -
bytebytebytebyte
VersionFlagName Size
Type SizeSpace Size

Name


Type


Space


Data

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Version

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

- - - - - - - - - - -
VersionDescription
2Used by the library of version 1.6.x and after to encode attribute message. - This version supports shared data type. The fields of name, type, and space - are not padded with additional bytes of zero.
-
Flag

This field indicates whether the data type of this attribute is shared:

- - - - - - - - - - - - - - - -
ValueDescription
0Datatype is not shared.
1Datatype is shared.
-
Name Size

The length of the attribute name in bytes including the - null terminator.

Datatype Size

The length of the datatype description in the Datatype - field below.

Dataspace Size

The length of the dataspace description in the Dataspace - field below.

Name

The null-terminated attribute name. This field is not - padded with additional bytes.

Datatype

The datatype description follows the same format as - described for the datatype object header message. This - field is not padded with additional bytes.

Dataspace

The dataspace description follows the same format as - described for the dataspace object header message. This - field is not padded with additional bytes.

Data

The raw data for the attribute. The size is determined - from the datatype and dataspace descriptions. This - field is not padded with additional zero - bytes.

-
- -
-

Name: Object Comment

- -

Header Message Type: 0x000D

-

Length: varies

-

Status: Optional, may not be repeated.

- -

Description: The object comment is - designed to be a short description of an object. An object comment - is a sequence of non-zero (\0) ASCII characters with no other - formatting included by the library.

- -

Format of Data: -
-

- - - - - - - - - - - - - -
- Name Message -
bytebytebytebyte

Comment

-
- -
-
- - - - - - - - - - -
Field NameDescription
NameA null terminated ASCII character string.
-
- -
-

Name: Object Modification Date & Time (Old)

- -

Header Message Type: 0x000E

-

Length: fixed

-

Status: Optional, may not be repeated.

- -

Description: The object modification date - and time is a timestamp which indicates (using ISO-8601 date and - time format) the last modification of an object. The time is - updated when any object header message changes according to the - system clock where the change was posted. - -

This modification time message is deprecated in favor of the "new" - modification time message (Message Type 0x0012) and is no longer written - to the file in versions of the HDF5 library after the 1.6.0 version. -

- -

Format of Data: -
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Modification Time Message -
bytebytebytebyte
Year
MonthDay of Month
HourMinute
SecondReserved
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Year

The four-digit year as an ASCII string. For example, - 1998. All fields of this message should be interpreted - as coordinated universal time (UTC)

Month

The month number as a two digit ASCII string where - January is 01 and December is 12.

Day of Month

The day number within the month as a two digit ASCII - string. The first day of the month is 01.

Hour

The hour of the day as a two digit ASCII string where - midnight is 00 and 11:00pm is 23.

Minute

The minute of the hour as a two digit ASCII string where - the first minute of the hour is 00 and - the last is 59.

Second

The second of the minute as a two digit ASCII string - where the first second of the minute is 00 - and the last is 59.

Reserved

This field is reserved and should always be zero.

-
- -
-

Name: Shared Object Message

-

Header Message Type: 0x000F

-

Length: Fixed

-

Status: Optional, may be repeated.

- -

Description: A constant message can be shared among - several object headers. A Shared Object Message contains the address of - the object message to be shared. Care must be exercised to prevent cycles when a - message of one object header points to a message in some other object header. - Starting from Version 2 of the Shared Object Message, the Flags - field becomes unused. -

- -

Format of Data: -
-

- - - - - - - - - - - - - - - - - - - -
- Shared Object Message (Version 1) -
byte - byte - byte - byte -
VersionFlagsReserved
Reserved

Pointer

-
- -
-
- - - - - - - - - - - - - - - - - - - -
Field NameDescription
Version

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

- - - - - - - - - - - - - - - -
VersionDescription
0Never used.
1Used by the library before version 1.6.1. In this version, - the Flags field is used to indicate whether the actual message is - stored in the global heap (never implemented). The Pointer field - either contains the header message address in the global heap - (never implemented) or the address of the shared object header.
-
Flags

The Shared Message message points to a message which is - shared among multiple object headers. The Flags field - describes the type of sharing:

- - - - - - - - - - - - - - - -
BitDescription
0If this bit is clear then the actual message is the - first message in some other object header; otherwise - the actual message is stored in the global heap (never - implemented).
2-7Reserved (always zero)
-
Pointer

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

-
- -
-
- - - - - - - - - - - - - - - -
- Shared Object Message (Version 2) -
byte - byte - byte - byte -
VersionFlags 

Pointer

-
- -
-
- - - - - - - - - - - - - - - - - - - -
Field NameDescription
Version

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

- - - - - - - - - - -
VersionDescription
2Used by the library of version 1.6.1 and after. In this version, - The Flags field is not used and the Pointer field contains the address - of the object header containing the message to be shared.
-
Flags

Unused.

Pointer

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

-
- - -
-

Name: Object Header Continuation

-

Header Message Type: 0x0010

-

Length: fixed

-

Status: Optional, may be repeated.

-

Description: The object header continuation is the location - in the file of more header messages for the current data object. This can be - used when header blocks become too large or are likely to change over time.

- -

Format of Data: -
-

- - - - - - - - - - - - - - - - - -
- Object Header Continuation Message -
bytebytebytebyte

Offset


Length

-
- -
-
- - - - - - - - - - - - - - - -
Field NameDescription
Offset

This value is the offset in bytes from the beginning of the file where the - header continuation information is located.

Length

This value is the length in bytes of the header continuation information in - the file.

-
- -
-

Name: Group Message

-

Header Message Type: 0x0011

-

Length: fixed

-

Status: Required for groups, may not be repeated.

-

Description: Each group has a B-tree and a - name heap which are pointed to by this message.

-

Format of data: - -
-

- - - - - - - - - - - - - - - - - -
- Group Message -
bytebytebytebyte

B-tree Address


Heap Address

-
- -
-
- - - - - - - - - - - - - - - -
Field NameDescription
B-tree Address

This value is the offset in bytes from the beginning of the file - where the B-tree is located.

Heap Address

This value is the offset in bytes from the beginning of the file - where the group name heap is located.

-
- -
-

Name: Object Modification Date & Time

- -

Header Message Type: 0x0012

-

Length: Fixed

-

Status: Optional, may not be repeated.

- -

Description: The object modification date - and time is a timestamp which indicates the last modification of an object. - The time is updated when any object header message changes according to the - system clock where the change was posted. -

- -

Format of Data: -

- - - - - - - - - - - - - - - - - - -
- Modification Time Message -
bytebytebytebyte
VersionReserved
Seconds After Epoch
-
- -
-
- - - - - - - - - - - - - - - - - - - - -
Field NameDescription
Version

The version number is used for changes in the format of Object Modification Time - and is described here:

- - - - - - - - - - - - - - - -
VersionDescription
0Never used.
1Used by Version 1.6.1 and after of the library to encode time. In - this version, the time is the seconds after Epoch.
-
Reserved

This field is reserved and should always be zero.

Seconds After Epoch

The number of seconds since 0 hours, 0 minutes, 0 seconds, - January 1, 1970, Coordinated Universal Time.

-
- -
-

Disk Format: Level 2b - Data Object Data Storage

-

The data for an object is stored separately from the header -information in the file and may not actually be located in the HDF5 file -itself if the header indicates that the data is stored externally. The -information for each record in the object is stored according to the -dimensionality of the object (indicated in the dimensionality header message). -Multi-dimensional data is stored in C order [same as current scheme], i.e. the -"last" dimension changes fastest. -

Data whose elements are composed of simple number-types are stored in -native-endian IEEE format, unless they are specifically defined as being stored -in a different machine format with the architecture-type information from the -number-type header message. This means that each architecture will need to -[potentially] byte-swap data values into the internal representation for that -particular machine. -

Data with a variable-length datatype is stored in the global heap -of the HDF5 file. Global heap identifiers are stored in the -data object storage. -

Data whose elements are composed of pointer number-types are stored in several -different ways depending on the particular pointer type involved. Simple -pointers are just stored as the dataset offset of the object being pointed to with the -size of the pointer being the same number of bytes as offsets in the file. -Dataset region references are stored as a heap-ID which points to the following -information within the file-heap: an offset of the object pointed to, number-type -information (same format as header message), dimensionality information (same -format as header message), sub-set start and end information (i.e. a coordinate -location for each), and field start and end names (i.e. a [pointer to the] -string indicating the first field included and a [pointer to the] string name -for the last field). - -

Data of a compound datatype is stored as a contiguous stream of the items -in the structure, with each item formatted according to its datatype.

- -
-

Appendix

-

Definitions of various terms used in this document. -

-

The "undefined address" for a file is a -file address with all bits set, i.e. 0xffff...ff. -

The "unlimited size" for a size is a -value with all bits set, i.e. 0xffff...ff. - -

- - diff --git a/doxygen/examples/H5.format.2.0.html b/doxygen/examples/H5.format.2.0.html deleted file mode 100644 index 789c6e501a9..00000000000 --- a/doxygen/examples/H5.format.2.0.html +++ /dev/null @@ -1,15255 +0,0 @@ - - - -HDF5 File Format Specification Version 2.0 - - - - -
-
- - - - - - - - -
-
    -
  1. Introduction
    2. - -
      -
    1. This Document
      2. -
    2. Changes for HDF5 1.10
      3. -
    -     - -
  2. Disk Format: Level 0 - File - Metadata
    3. - -
      -
    1. Disk Format: Level 0A - Format - Signature and Superblock
      2. -
    2. Disk Format: Level 0B - File - Driver Info
      3. -
    3. Disk Format: Level 0C - - Superblock Extension
      4. -
    -     -
  3. Disk Format: Level 1 - File - Infrastructure
    4. - -
      -
    1. Disk Format: Level 1A - B-trees - and B-tree Nodes
      2. -
        -
      1. Disk Format: Level 1A1 - - Version 1 B-trees (B-link Trees)
        2. -
      2. Disk Format: Level 1A2 - - Version 2 B-trees
        3. -
      -
    2. Disk Format: Level 1B - Group - Symbol Table Nodes
      3. -
    3. Disk Format: Level 1C - - Symbol Table Entry
      4. -
    4. Disk Format: Level 1D - Local - Heaps
      5. -
    5. Disk Format: Level 1E - Global - Heap
      6. -
    6. Disk Format: Level 1F - - Fractal Heap
      7. -
    7. Disk Format: Level 1G - - Free-space Manager
      8. -
    8. Disk Format: Level 1H - Shared - Object Header Message Table
      9. -
    -     -
  4. Disk Format: Level 2 - Data - Objects
    5. - -
      -
    1. Disk Format: Level 2A - Data - Object Headers
      2. -
        -
      1. Disk Format: Level - 2A1 - Data Object Header Prefix
        2. -
          -
        1. Version 1 Data - Object Header Prefix
          2. -
        2. Version 2 Data - Object Header Prefix
          3. -
        -
      2. Disk Format: Level - 2A2 - Data Object Header Messages
        3. -
          -
        1. The NIL Message
          2. - -
        2. The Dataspace Message
          3. - -
        3. The Link Info Message
          4. - -
        -
      -
    -     -
- 		  -
    -
  1. Disk Format: Level 2 - Data - Objects (Continued)
    2. -
      -
    1. Disk Format: Level 2A - Data - Object Headers (Continued)
      2. -
        -
      1. Disk Format: Level - 2A2 - Data Object Header Messages (Continued)
        2. -
          -
        1. The Datatype Message
          2. - -
        2. The Data Storage - - Fill Value (Old) Message
          3. - -
        3. The Data Storage - Fill - Value Message
          4. - -
        4. The Link Message
          5. - -
        5. The Data Storage - - External Data Files Message
          6. - -
        6. The Data Storage - Layout - Message
          7. - -
        7. The Bogus Message
          8. - -
        8. The Group Info Message
          9. - -
        9. The Data Storage - Filter - Pipeline Message
          10. - -
        10. The Attribute Message
          11. - -
        11. The Object Comment - Message
          12. - -
        12. The Object - Modification Time (Old) Message
          13. - -
        13. The Shared Message - Table Message
          14. - -
        14. The Object Header - Continuation Message
          15. - -
        15. The Symbol Table - Message
          16. - -
        16. The Object - Modification Time Message
          17. - -
        17. The B-tree - ‘K’ Values Message
          18. - -
        18. The Driver Info Message
          19. - -
        19. The Attribute Info Message
          20. - -
        20. The Object Reference - Count Message
          21. - -
        21. The File Space Info - Message
          22. - -
        -
      -
    2. Disk Format: Level 2B - Data - Object Data Storage
      3. -
    - -
  2. Appendix A: Definitions
    3. -
  3. Appendix B: File Memory - Allocation Types
    4. -
-
-
- - - -
-
-
-

I. Introduction

 - - - - - - - - - - - - - - - - - - - - - - - -
  -
HDF5 Groups - 		 
 Figure 1: Relationships among - the HDF5 root group, other groups, and objects -
 
 HDF5 Objects 
 Figure 2: HDF5 objects -- - datasets, datatypes, or dataspaces -
 
- - -

The format of an HDF5 file on disk encompasses several key ideas - of the HDF4 and AIO file formats as well as addressing some - shortcomings therein. The new format is more self-describing than the - HDF4 format and is more uniformly applied to data objects in the file.

- -

An HDF5 file appears to the user as a directed graph. The nodes - of this graph are the higher-level HDF5 objects that are exposed by the - HDF5 APIs:

- - - -

At the lowest level, as information is actually written to the - disk, an HDF5 file is made up of the following objects:

- - -

The HDF5 Library uses these low-level objects to represent the - higher-level objects that are then presented to the user or to - applications through the APIs. For instance, a group is an object - header that contains a message that points to a local heap (for storing - the links to objects in the group) and to a B-tree (which indexes the - links). A dataset is an object header that contains messages that - describe datatype, dataspace, layout, filters, external files, fill - value, and other elements with the layout message pointing to either a - raw data chunk or to a B-tree that points to raw data chunks.

- - -
-

I.A. This Document

 - -

- This document describes the lower-level data objects; the higher-level - objects and their properties are described in the HDF5 - User Guide. -

- -

- Three levels of information comprise the file format. Level 0 contains - basic information for identifying and defining information about the - file. Level 1 information contains the information about the pieces of - a file shared by many objects in the file (such as a B-trees and - heaps). Level 2 is the rest of the file and contains all of the data - objects, with each object partitioned into header information, also - known as metadata, and data. -

- -

- The sizes of various fields in the following layout tables are - determined by looking at the number of columns the field spans in the - table. There are three exceptions: (1) The size may be overridden by - specifying a size in parentheses, (2) the size of addresses is - determined by the Size of Offsets field in the superblock and - is indicated in this document with a superscripted ‘O’, and - (3) the size of length fields is determined by the Size of - Lengths field in the superblock and is indicated in this document with - a superscripted ‘L’. -

- -

Values for all fields in this document should be treated as - unsigned integers, unless otherwise noted in the description of a - field. Additionally, all metadata fields are stored in little-endian - byte order.

- -

- All checksums used in the format are computed with the Jenkins’ - lookup3 algorithm. -

- -

Whenever a bit flag or field is mentioned for an entry, bits are - numbered from the lowest bit position in the entry.

- -

Various tables in this document aligned with “This space - inserted only to align table nicely”. These entries in the table - are just to make the table presentation nicer and do not represent any - values or padding in the file.

- - -
-

I.B. Changes for HDF5 1.10

 - -

As of October 2015, changes in the file format for HDF5 1.10 have - not yet been finalized.

- - - -
-
-
-

- II. Disk Format: Level 0 - File Metadata -

- -
-

- II.A. Disk Format: Level 0A - Format - Signature and Superblock -

- -

The superblock may begin at certain predefined offsets within the - HDF5 file, allowing a block of unspecified content for users to place - additional information at the beginning (and end) of the HDF5 file - without limiting the HDF5 Library’s ability to manage the objects - within the file itself. This feature was designed to accommodate - wrapping an HDF5 file in another file format or adding descriptive - information to an HDF5 file without requiring the modification of the - actual file’s information. The superblock is located by searching - for the HDF5 format signature at byte offset 0, byte offset 512, and at - successive locations in the file, each a multiple of two of the - previous location; in other words, at these byte offsets: 0, 512, 1024, - 2048, and so on.

- -

The superblock is composed of the format signature, followed by a - superblock version number and information that is specific to each - version of the superblock. Currently, there are three versions of the - superblock format. Version 0 is the default format, while version 1 is - basically the same as version 0 with additional information when a - non-default B-tree ‘K’ value is stored. Version 2 is the - latest format, with some fields eliminated or compressed and with - superblock extension and checksum support.

- -

Version 0 and 1 of the superblock are described below:

- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Superblock (Versions 0 and 1)
bytebytebytebyte

Format Signature (8 bytes)
-
Version # of SuperblockVersion # of File’s Free Space StorageVersion # of Root Group Symbol Table EntryReserved (zero)
Version # of Shared Header Message FormatSize of OffsetsSize of LengthsReserved (zero)
Group Leaf Node KGroup Internal Node K
File Consistency Flags
Indexed Storage Internal - Node K1 - Reserved (zero)1

Base AddressO
-

Address of File Free space InfoO
-

End of File AddressO
-

Driver Information Block AddressO
-
Root Group Symbol Table Entry
- - - - - - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets.”)
 (Items marked with a ‘1’ in the above table are - new in version 1 of the superblock)
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Decimal:13772687013102610
Hexadecimal:894844460d0a1a0a
ASCII C Notation:\211HDF\r\n\032\n
-
-

- 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 version 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 value contains flags to indicate information about the - consistency of the information contained within the file. - Currently, the following bit flags are defined:

-
    -
  • Bit 0 set indicates that the file is opened for - write-access.
    • -
  • Bit 1 set indicates that the file has been verified for - consistency and is guaranteed to be consistent with the format - defined in this document.
    • -
  • Bits 2-31 are reserved for future use.
    • -
Bit 0 should be set as the first action when a file is opened for - write access and should be cleared only as the final action when - closing a file. Bit 1 should be cleared during normal access to a - file and only set after the file’s consistency is guaranteed - by the library or a consistency utility. -

- -

- 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 accidentally 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. -

-
-
- -
-

Version 2 of the superblock is described below:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Superblock (Version 2)
bytebytebytebyte

Format Signature (8 bytes)
-
Version # of SuperblockSize of OffsetsSize of LengthsFile Consistency Flags

Base AddressO
-

Superblock Extension AddressO
-

End of File AddressO
-

Root Group Object Header AddressO
-
Superblock Checksum
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets.”)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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

 -

This field is the same as described for versions 0 and 1 - except that it is smaller (the number of reserved bits has been - reduced from 30 to 6).

-

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.

-
-
- -
-

- II.B. Disk Format: Level 0B - File Driver - Info -

- -

- The driver information block is an optional region of the file - which contains information needed by the file driver to reopen a file. - The format is described below: -

- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - -
Driver Information Block
bytebytebytebyte
VersionReserved
Driver Information Size

Driver Identification (8 bytes)
-

-
Driver Information (variable size)
-
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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

Driver information is stored in a format defined by the file - driver (see description below).
-
- -
The two drivers encoded in the -Driver Identification field are as follows: - -

- The format of the Driver Information field for the above two - drivers are described below: -

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Multi Driver Information
bytebytebytebyte
Member MappingMember MappingMember MappingMember Mapping
Member MappingMember MappingReservedReserved

Address of Member File 1
-

End of Address for Member File 1
-

Address of Member File 2
-

End of Address for Member File 2
-

... ...
-

Address of Member File N
-

End of Address for Member File N
-

Name of Member File 1 (variable - size)
-

Name of Member File 2 (variable - size)
-

... ...
-

Name of Member File N (variable - size)
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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 MappingDescription
1The superblock data.
2The B-tree data.
3The raw data.
4The global heap data.
5The local heap data.
6The 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. -

-
- -
-
- - - - - - - - - - - - - - -
Family Driver Information
bytebytebytebyte

Size of Member File
-
-
- -
-
- - - - - - - - - - -
Field NameDescription

Size of Member File

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

-
- -
-

- II.C. Disk Format: Level 0C - Superblock - Extension -

- -

- The superblock extension is used to store superblock metadata - which is either optional, or added after the version of the superblock - was defined. Superblock extensions may only exist when version 2+ of - superblock is used. A superblock extension is an object header which - may hold the following messages: -

- - - - -
-
-
-

- III. Disk Format: Level 1 - File - Infrastructure -

- -
-

- III.A. Disk Format: Level 1A - B-trees and B-tree - Nodes -

- -

B-trees allow flexible storage for objects which tend to grow in - ways that cause the object to be stored discontiguously. B-trees are - described in various algorithms books including “Introduction to - Algorithms” by Thomas H. Cormen, Charles E. Leiserson, and Ronald - L. Rivest. B-trees are used in several places in the HDF5 file format, - when an index is needed for another data structure.

- -

The version 1 B-tree structure described below is the original - index structure, but are limited by some bugs in our implementation - (mainly in how they handle deleting records). The version 1 B-trees are - being phased out in favor of the version 2 B-trees described below, - although both types of structures may be found in the same file, - depending on application settings when creating the file.

- -
-

- III.A.1. Disk Format: Level 1A1 - Version 1 - B-trees (B-link Trees) -

- -

- Version 1 B-trees in HDF5 files an implementation of the B-link tree, - in which the sibling nodes at a particular level in the tree are stored - in a doubly-linked list, is described in the “Efficient Locking - for Concurrent Operations on B-trees” paper by Phillip Lehman and - S. Bing Yao as published in the ACM Transactions on - Database Systems, Vol. 6, No. 4, December 1981. -

- -

The B-link trees implemented by the file format contain one more - key than the number of children. In other words, each child pointer out - of a B-tree node has a left key and a right key. The pointers out of - internal nodes point to sub-trees while the pointers out of leaf nodes - point to symbol nodes and raw data chunks. Aside from that difference, - internal nodes and leaf nodes are identical.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
B-link Tree Nodes
bytebytebytebyte
Signature
Node TypeNode LevelEntries Used

Address of Left SiblingO
-

Address of Right SiblingO
-
Key 0 (variable size)

Address of Child 0O
-
Key 1 (variable size)

Address of Child 1O
-
...
Key 2K (variable size) -

Address of Child 2KO
-
Key 2K+1 (variable size) -
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Signature

 -

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

-

Node Type

 -

- Each B-link 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 TypeDescription
0This tree points to group nodes.
1This 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-link 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. -

-
-
- -

Conceptually, each B-tree node looks like this:

-
- - - - - - - - - - - - - - - - - - - - - - -
key[0] child[0] key[1] child[1] key[2] ... ... key[N-1] -  child[N-1] -  key[N] -
-
-
where child[ -i] is a pointer to a sub-tree (at a level above Level 0) or to -data (at Level 0). Each key[ -i] describes an -item stored by the B-tree (a chunk or an object of a group node). -The range of values represented by child[ -i] is indicated by key[ -i] and key[ -i+1]. - - -

- The following question must next be answered: “Is the value - described by key[i] contained in child[i-1] or in child[i]?” - The answer depends on the type of tree. In trees for groups (node type - 0) the object described by key[i] is the greatest object - contained in child[i-1] while in chunk trees (node type 1) the - chunk described by key[i] is the least chunk in child[i]. -

- -

That means that key[0] for group trees is sometimes unused; it - points to offset zero in the heap, which is always the empty string and - compares as “less-than” any valid object name.

- -

- And key[N] for chunk trees is sometimes unused; it contains a - chunk offset which compares as “greater-than” any other - chunk offset and has a chunk byte size of zero to indicate that it is - not actually allocated. -

- -
-

- III.A.2. Disk Format: Level 1A2 - Version 2 - B-trees -

- -

- Version 2 B-trees are “traditional” B-trees, with one major - difference. Instead of just using a simple pointer (or address in the - file) to a child of an internal node, the pointer to the child node - contains two additional pieces of information: the number of records in - the child node itself, and the total number of records in the child - node and all its descendants. Storing this additional information - allows fast array-like indexing to locate the nth record in - the B-tree. -

- -

- The entry into a version 2 B-tree is a header which contains global - information about the structure of the B-tree. The root node - address field in the header points to the B-tree root node, which is - either an internal or leaf node, depending on the value in the - header’s depth field. An internal node consists of - records plus pointers to further leaf or internal nodes in the tree. A - leaf node consists of solely of records. The format of the records - depends on the B-tree type (stored in the header). -

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Version 2 B-tree Header
bytebytebytebyte
Signature
VersionTypeThis space inserted - only to align table nicely
Node Size
Record SizeDepth
Split PercentMerge PercentThis space inserted - only to align table nicely

Root Node AddressO
-
Number of Records in Root NodeThis space inserted - only to align table nicely

Total Number of Records in B-treeL
-
Checksum
- - - - - - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
 (Items marked with an ‘L’ in the above table are - of the size specified in “Size of Lengths” field in the - superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Signature

 -

- The ASCII character string “ - BTHD - ” is used to indicate the header of a version 2 B-link 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:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0A “testing” B-tree, this value should not - be used for storing records in actual HDF5 files. -
1This B-tree is used for indexing indirectly accessed, - non-filtered ‘huge’ fractal heap objects.
2This B-tree is used for indexing indirectly accessed, - filtered ‘huge’ fractal heap objects.
3This B-tree is used for indexing directly accessed, - non-filtered ‘huge’ fractal heap objects.
4This B-tree is used for indexing directly accessed, - filtered ‘huge’ fractal heap objects.
5This B-tree is used for indexing the ‘name’ - field for links in indexed groups.
6This B-tree is used for indexing the ‘creation - order’ field for links in indexed groups.
7This B-tree is used for indexing shared object header - messages.
8This B-tree is used for indexing the ‘name’ - field for indexed attributes.
9This B-tree is used for indexing the ‘creation - order’ field for indexed attributes.
-

-

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.

-
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Version 2 B-tree Internal Node
bytebytebytebyte
Signature
VersionTypeRecords 0, 1, 2...N-1 (variable size)

Child Node Pointer 0O
-

Number of Records N0 for Child - Node 0 (variable size)

Total Number of Records for Child Node 0 - (optional, variable size)

Child Node Pointer 1O
-

Number of Records N1 for Child - Node 1 (variable size)

Total Number of Records for Child Node 1 - (optional, variable size)
...

Child Node Pointer NO
-

Number of Records Nn for Child - Node N (variable size)

Total Number of Records for Child Node N - (optional, variable size)
Checksum
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
-
- - -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Signature

 -

- The ASCII character string “ - BTIN - ” is used to indicate the internal node of a B-link 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.

-
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - -
Version 2 B-tree Leaf Node
bytebytebytebyte
Signature
VersionTypeRecord 0, 1, 2...N-1 (variable size)
Checksum
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Signature

 -

- The ASCII character string “ - BTLF - “ is used to indicate the leaf node of a version 2 B-link - 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.

-
-
- -
-

The record layout for each stored (in other words, non-testing) - B-tree type is as follows:

- -
- - - - - - - - - - - - - - - - - - - -
Version 2 B-tree, Type 1 Record Layout - Indirectly - Accessed, Non-Filtered, ‘Huge’ Fractal Heap Objects
bytebytebytebyte

Huge Object AddressO
-

Huge Object LengthL
-

Huge Object IDL
-
- - - - - - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
 (Items marked with an ‘L’ in the above table are - of the size specified in “Size of Lengths” field in the - superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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.

-
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
Version 2 B-tree, Type 2 Record Layout - Indirectly - Accessed, Filtered, ‘Huge’ Fractal Heap Objects
bytebytebytebyte

Filtered Huge Object AddressO
-

Filtered Huge Object LengthL
-
Filter Mask

Filtered Huge Object Memory SizeL
-

Huge Object IDL
-
- - - - - - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
 (Items marked with an ‘L’ in the above table are - of the size specified in “Size of Lengths” field in the - superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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.

-
-
- -
-
-
- - - - - - - - - - - - - - - - -
Version 2 B-tree, Type 3 Record Layout - Directly - Accessed, Non-Filtered, ‘Huge’ Fractal Heap Objects
bytebytebytebyte

Huge Object AddressO
-

Huge Object LengthL
-
- - - - - - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
 (Items marked with an ‘L’ in the above table are - of the size specified in “Size of Lengths” field in the - superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - -
Field NameDescription

Huge Object Address

 -

The address of the huge object in the file.

-

Huge Object Length

 -

The length of the huge object in the file.

-
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - -
Version 2 B-tree, Type 4 Record Layout - Directly - Accessed, Filtered, ‘Huge’ Fractal Heap Objects
bytebytebytebyte

Filtered Huge Object AddressO
-

Filtered Huge Object LengthL
-
Filter Mask

Filtered Huge Object Memory SizeL
-
- - - - - - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
 (Items marked with an ‘L’ in the above table are - of the size specified in “Size of Lengths” field in the - superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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.

-
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - -
Version 2 B-tree, Type 5 Record Layout - Link Name - for Indexed Group
bytebytebytebyte
Hash of Name
ID (bytes 1-4)
ID (bytes 5-7)
-
- -
-
- - - - - - - - - - - - - - - - -
Field NameDescription

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.

-
-
- -
-
-
- - - - - - - - - - - - - - - - - - - -
Version 2 B-tree, Type 6 Record Layout - Creation - Order for Indexed Group
bytebytebytebyte

Creation Order (8 bytes)
-
ID (bytes 1-4)
ID (bytes 5-7)
-
- -
-
- - - - - - - - - - - - - - - - -
Field NameDescription

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.

-
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
Version 2 B-tree, Type 7 Record Layout - Shared - Object Header Messages (Sub-Type 0 - Message in Heap)
bytebytebytebyte
Message LocationThis space inserted - only to align table nicely
Hash
Reference Count

Heap ID (8 bytes)
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Message Location

 -

This field Indicates the location where the message is - stored:

- - - - - - - - - - - - - -
ValueDescription
0Shared message is stored in shared message index heap.
1Shared 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.

-
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
Version 2 B-tree, Type 7 Record Layout - Shared - Object Header Messages (Sub-Type 1 - Message in Object Header)
bytebytebytebyte
Message LocationThis space inserted - only to align table nicely
Hash
Reserved (zero)Message TypeObject Header Index

Object Header AddressO
-
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Message Location

 -

This field Indicates the location where the message is - stored:

- - - - - - - - - - - - - -
ValueDescription
0Shared message is stored in shared message index heap.
1Shared 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 nth - message of its type in the specified object header. -

-

Object Header Address

 -

The address of the object header containing the shared - message.

-
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
Version 2 B-tree, Type 8 Record Layout - Attribute - Name for Indexed Attributes
bytebytebytebyte

Heap ID (8 bytes)
-
Message FlagsThis space inserted - only to align table nicely
Creation Order
Hash of Name
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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.

-
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - -
Version 2 B-tree, Type 9 Record Layout- Creation - Order for Indexed Attributes
bytebytebytebyte

Heap ID (8 bytes)
-
Message FlagsThis space inserted - only to align table nicely
Creation Order
-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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.

-
-
- - -
-

- III.B. Disk Format: Level 1B - Group Symbol - Table Nodes -

- -

A group is an object internal to the file that allows arbitrary - nesting of objects within the file (including other groups). A group - maps a set of link names in the group to a set of relative file - addresses of objects in the file. Certain metadata for an object to - which the group points can be cached in the group’s symbol table - entry in addition to being in the object’s header.

- -

An HDF5 object name space can be stored hierarchically by - partitioning the name into components and storing each component as a - link in a group. The link for a non-ultimate component points to the - group containing the next component. The link for the last component - points to the object being named.

- -

- One implementation of a group is a collection of symbol table nodes - indexed by a B-link tree. Each symbol table node contains entries for - one or more links. If an attempt is made to add a link to an already - full symbol table node containing 2K entries, then the node is - split and one node contains K symbols and the other contains K+1 - symbols. -

- -
- - - - - - - - - - - - - - - - - - - - - - - -
Symbol Table Node (A Leaf of a B-link tree)
bytebytebytebyte
Signature
Version NumberReserved (zero)Number of Symbols

-
Group Entries
-
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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. -

-
-
- -
-

- III.C. Disk Format: Level 1C - Symbol - Table Entry -

- -

Each symbol table entry in a symbol table node is designed to - allow for very fast browsing of stored objects. Toward that design - goal, the symbol table entries include space for caching certain - constant metadata from the object header.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Symbol Table Entry
bytebytebytebyte

Link Name OffsetO
-

Object Header AddressO
-
Cache Type
Reserved (zero)

-
Scratch-pad Space (16 bytes)
-
-
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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:

- - - - - - - - - - - - - - - - - -
TypeDescription
0No 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.
1Group object header metadata is cached in the scratch-pad - space. This implies that the symbol table entry refers to another - group.
2The 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.

-
-
- -
-

Format of the Scratch-pad Space

- -

The symbol table entry scratch-pad space is formatted according - to the value in the Cache Type field.

- -

- If the Cache Type field contains the value zero - (0) - then no information is stored in the scratch-pad space. -

- -

- If the Cache Type field contains the value one - (1) - , then the scratch-pad space contains cached metadata for another - object header in the following format: -

- -
- - - - - - - - - - - - - - - - - -
Object Header Scratch-pad Format
bytebytebytebyte

Address of B-treeO
-

Address of Name HeapO
-
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - -
Field NameDescription

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.

-
-
- - -
-

- If the Cache Type field contains the value two - (2) - , then the scratch-pad space contains cached metadata for a symbolic - link in the following format: -

- -
- - - - - - - - - - - - - -
Symbolic Link Scratch-pad Format
bytebytebytebyte
Offset to Link Value
-
- -
-
- - - - - - - - - - -
Field NameDescription

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.

-
-
- -
-

- III.D. Disk Format: Level 1D - Local Heaps -

- -

A local heap is a collection of small pieces of data that are - particular to a single object in the HDF5 file. Objects can be inserted - and removed from the heap at any time. The address of a heap does not - change once the heap is created. For example, a group stores addresses - of objects in symbol table nodes with the names of links stored in the - group’s local heap.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Local Heap
bytebytebytebyte
Signature
VersionReserved (zero)

Data Segment SizeL
-

Offset to Head of Free-listL
-

Address of Data SegmentO
-
- - - - - - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
 (Items marked with an ‘L’ in the above table are - of the size specified in “Size of Lengths” field in the - superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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.

-
-
- -

Objects within a local heap should be aligned on an 8-byte - boundary.

- -
-

- III.E. Disk Format: Level 1E - Global Heap -

- -

Each HDF5 file has a global heap which stores various types of - information which is typically shared between datasets. The global heap - was designed to satisfy these goals:

- -
    -
  1. Repeated access to a heap object must be efficient without - resulting in repeated file I/O requests. Since global heap objects - will typically be shared among several datasets, it is probable that - the object will be accessed repeatedly.
    2. -
  2. Collections of related global heap objects should result in - fewer and larger I/O requests. For instance, a dataset of object - references will have a global heap object for each reference. Reading - the entire set of object references should result in a few large I/O - requests instead of one small I/O request for each reference.
    3. -
  3. It should be possible to remove objects from the global heap - and the resulting file hole should be eligible to be reclaimed for - other uses.
    4. -
- - -

- The implementation of the heap makes use of the memory management - already available at the file level and combines that with a new object - called a collection to achieve goal B. The global heap is the - set of all collections. Each global heap object belongs to exactly one - collection and each collection contains one or more global heap - objects. For the purposes of disk I/O and caching, a collection is - treated as an atomic object, addressing goal A. -

- -

When a global heap object is deleted from a collection (which - occurs when its reference count falls to zero), objects located after - the deleted object in the collection are packed down toward the - beginning of the collection and the collection’s global heap - object 0 is created (if possible) or its size is increased to account - for the recently freed space. There are no gaps between objects in each - collection, with the possible exception of the final space in the - collection, if it is not large enough to hold the header for the - collection’s global heap object 0. These features address goal C. -

- -

The HDF5 Library creates global heap collections as needed, so - there may be multiple collections throughout the file. The set of all - of them is abstractly called the “global heap”, although - they do not actually link to each other, and there is no global place - in the file where you can discover all of the collections. The - collections are found simply by finding a reference to one through - another object in the file. For example, data of variable-length - datatype elements is stored in the global heap and is accessed via a - global heap ID. The format for global heap IDs is described at the end - of this section.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
A Global Heap Collection
bytebytebytebyte
Signature
VersionReserved (zero)

Collection SizeL
-

Global Heap Object 1
-

Global Heap Object 2
-

...
-

Global Heap Object N
-

Global Heap Object 0 (free space)
-
- - - - - - -
 (Items marked with an ‘L’ in the - above table are of the size specified in “Size of - Lengths” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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 the collection contains no free space.

-
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
Global Heap Object
bytebytebytebyte
Heap Object IndexReference Count
Reserved (zero)

Object SizeL
-

Object Data
-
- - - - - - -
 (Items marked with an ‘L’ in the - above table are of the size specified in “Size of - Lengths” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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.

-
- -
- -
-

The format for the ID used to locate an object in the global heap - is described here:

- -
- - - - - - - - - - - - - - - - - -
Global Heap ID
bytebytebytebyte

Collection AddressO
-
Object Index
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - -
Field NameDescription

Collection Address

 -

This field is the address of the global heap collection where - the data object is stored.

-

ID

 -

This field is the index of the data object within the global - heap collection.

-
-
- - -
-

- III.F. Disk Format: Level 1F - Fractal Heap -

- -

- Each fractal heap consists of a header and zero or more direct and - indirect blocks (described below). The header contains general - information as well as initialization parameters for the doubling - table. The Root Block Address in the header points to the - first direct or indirect block in the heap. -

- -

- Fractal heaps are based on a data structure called a doubling - table. A doubling table provides a mechanism for quickly extending an - array-like data structure that minimizes the number of empty blocks in - the heap, while retaining very fast lookup of any element within the - array. More information on fractal heaps and doubling tables can be - found in the RFC “Private Heaps in - HDF5.” -

- -

The fractal heap implements the doubling table structure with - indirect and direct blocks. Indirect blocks in the heap do not actually - contain data for objects in the heap, their “size” is - abstract - they represent the indexing structure for locating the - direct blocks in the doubling table. Direct blocks contain the actual - data for objects stored in the heap.

- -

- All indirect blocks have a constant number of block entries in each - row, called the width of the doubling table (stored in the - heap header). The number of rows for each indirect block in the heap is - determined by the size of the block that the indirect block represents - in the doubling table (calculation of this is shown below) and is - constant, except for the “root” indirect block, which - expands and shrinks its number of rows as needed. -

- -

- Blocks in the first two rows of an indirect block are Starting - Block Size number of bytes in size, and the blocks in each subsequent - row are twice the size of the blocks in the previous row. In other - words, blocks in the third row are twice the Starting Block - Size, blocks in the fourth row are four times the Starting - Block Size, and so on. Entries for blocks up to the Maximum - Direct Block Size point to direct blocks, and entries for blocks - greater than that size point to further indirect blocks (which have - their own entries for direct and indirect blocks). -

- -

- The number of rows of blocks, nrows, in an indirect block of - size iblock_size is given by the following expression:
-
nrows = (log2(iblock_size) - log2(<Starting - Block Size> * <Width>)) + 1 -

- -

- The maximum number of rows of direct blocks, max_dblock_rows, - in any indirect block of a fractal heap is given by the following - expression:

max_dblock_rows = (log2(<Max. - Direct Block Size>) - log2(<Starting Block - Size>)) + 2 -

- -

- Using the computed values for nrows and max_dblock_rows, - along with the Width of the doubling table, the number of - direct and indirect block entries (K and N in the - indirect block description, below) in an indirect block can be - computed:

K = MIN(nrows, max_dblock_rows) - * Width

If nrows is less than or - equal to max_dblock_rows, N is 0. Otherwise, N - is simply computed:

N = K - (max_dblock_rows - * Width) -

- -

The size indirect blocks on disk is determined by the number of - rows in the indirect block (computed above). The size of direct blocks - on disk is exactly the size of the block in the doubling table.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Fractal Heap Header
bytebytebytebyte
Signature
VersionThis space inserted - only to align table nicely
Heap ID LengthI/O Filters’ Encoded Length
FlagsThis space inserted - only to align table nicely
Maximum Size of Managed Objects

Next Huge Object IDL
-

v2 B-tree Address of Huge ObjectsO
-

Amount of Free Space in Managed BlocksL
-

Address of Managed Block Free Space - ManagerO
-

Amount of Managed Space in HeapL
-

Amount of Allocated Managed Space in HeapL
-

Offset of Direct Block Allocation - Iterator in Managed SpaceL
-

Number of Managed Objects in HeapL
-

Size of Huge Objects in HeapL
-

Number of Huge Objects in HeapL
-

Size of Tiny Objects in HeapL
-

Number of Tiny Objects in HeapL
-
Table WidthThis space inserted - only to align table nicely

Starting Block SizeL
-

Maximum Direct Block SizeL
-
Maximum Heap SizeStarting # of Rows in Root Indirect Block

Address of Root BlockO
-
Current # of Rows in Root Indirect BlockThis space inserted - only to align table nicely

Size of Filtered Root Direct Block (optional)L
-
I/O Filter Mask (optional)
I/O Filter Information (optional, - variable size)
Checksum
- - - - - - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
 (Items marked with an ‘L’ in the above table are - of the size specified in “Size of Lengths” field in the - superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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
0If 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. -
1If set, the direct blocks in the heap are checksummed.
2-7Reserved
-

- -

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 & - 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 # 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 # 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.

-
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Fractal Heap Direct Block
bytebytebytebyte
Signature
VersionThis space inserted - only to align table nicely

Heap Header AddressO
-
Block Offset (variable size)
Checksum (optional)

Object Data (variable size)
-
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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). -

-
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Fractal Heap Indirect Block
bytebytebytebyte
Signature
VersionThis space inserted - only to align table nicely

Heap Header AddressO
-
Block Offset (variable size)

Child Direct Block #0 AddressO
-

Size of Filtered Direct Block #0 (optional) - L
-
Filter Mask for Direct Block #0 (optional)

Child Direct Block #1 AddressO
-

Size of Filtered Direct Block #1 (optional)L
-
Filter Mask for Direct Block #1 (optional)
...

Child Direct Block #K-1 AddressO
-

Size of Filtered Direct Block #K-1 (optional)L
-
Filter Mask for Direct Block #K-1 (optional)

Child Indirect Block #0 AddressO
-

Child Indirect Block #1 AddressO
-
...

Child Indirect Block #N-1 AddressO
-
Checksum
- - - - - - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
 (Items marked with an ‘L’ in the above table are - of the size specified in “Size of Lengths” field in the - superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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.

-
- -
- -
-

An object in the fractal heap is identified by means of a fractal - heap ID, which encodes information to locate the object in the heap. - Currently, the fractal heap stores an object in one of three ways, - depending on the object’s size:

- -
- - - - - - - - - - - - - - - - - - - - -
TypeDescription
Tiny -

When an object is small enough to be encoded in the heap ID, - the object’s data is embedded in the fractal heap ID itself. - There are 2 sub-types for this type of object: normal and extended. - The sub-type for tiny heap IDs depends on whether the heap ID is - large enough to store objects greater than 16 bytes or not. If the - heap ID length is 18 bytes or smaller, the ‘normal’ - tiny heap ID form is used. If the heap ID length is greater than 18 - bytes in length, the “extended” form is used. See - format description below for both sub-types.

-
Huge -

- When the size of an object is larger than Maximum Size of - Managed Objects in the Fractal Heap Header, the - object’s data is stored on its own in the file and the object - is tracked/indexed via a version 2 B-tree. All huge objects for a - particular fractal heap use the same v2 B-tree. All huge objects - for a particular fractal heap use the same format for their huge - object IDs. -

- -

Depending on whether the IDs for a heap are large enough to - hold the object’s retrieval information and whether I/O - pipeline filters are applied to the heap’s objects, 4 - sub-types are derived for huge object IDs for this heap:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - -
Sub-typeDescription
Directly accessed, non-filtered -

The object’s address and length are embedded in the - fractal heap ID itself and the object is directly accessed from - them. This allows the object to be accessed without resorting - to the B-tree.

-
Directly accessed, filtered -

The filtered object’s address, length, filter mask - and de-filtered size are embedded in the fractal heap ID itself - and the object is accessed directly with them. This allows the - object to be accessed without resorting to the B-tree.

-
Indirectly accessed, non-filtered -

The object is located by using a B-tree key embedded in - the fractal heap ID to retrieve the address and length from the - version 2 B-tree for huge objects. Then, the address and length - are used to access the object.

-
Indirectly accessed, filtered -

The object is located by using a B-tree key embedded in - the fractal heap ID to retrieve the filtered object’s - address, length, filter mask and de-filtered size from the - version 2 B-tree for huge objects. Then, this information is - used to access the object.

-
-
- -
Managed -

When the size of an object does not meet the above two - conditions, the object is stored and managed via the direct and - indirect blocks based on the doubling table.

-
-
- - -

The specific format for each type of heap ID is described below: -

- -
- - - - - - - - - - - - - - - - - - - -
Fractal Heap ID for Tiny Objects (sub-type 1 - - ‘Normal’)
bytebytebytebyte
Version, Type & LengthThis space inserted - only to align table nicely

Data (variable size)
-
- -
-
- - - - - - - - - - - - - - - - -
Field NameDescription

Version, Type & Length

 -

This is a bit field with the following definition:

- - - - - - - - - - - - - - - - - - -
BitDescription
6-7The current version of ID format. This document describes - version 0.
4-5The ID type. Tiny objects have a value of 2. -
0-3The 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.

-
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - -
Fractal Heap ID for Tiny Objects (sub-type 2 - - ‘Extended’)
bytebytebytebyte
Version, Type & LengthExtended LengthThis space inserted - only to align table nicely
Data (variable size)
-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version, Type & Length

 -

This is a bit field with the following definition:

- - - - - - - - - - - - - - - - - - -
BitDescription
6-7The current version of ID format. This document describes - version 0.
4-5The ID type. Tiny objects have a value of 2. -
0-3These 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.

-
-
- - -
-
-
- - - - - - - - - - - - - - - - - - - -
Fractal Heap ID for Huge Objects (sub-type 1 & 2): - indirectly accessed, non-filtered/filtered
bytebytebytebyte
Version & TypeThis space inserted - only to align table nicely

v2 B-tree KeyL - (variable size)
-
- - - - - - -
 (Items marked with an ‘L’ in the - above table are of the size specified in “Size of - Lengths” field in the superblock.)
-
- -
-
- - - - - - - - - - - - - - - - -
Field NameDescription

Version & Type

 -

This is a bit field with the following definition:

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

- -

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-type 1 & 2 for a description of the fields. New key values are - derived from Next Huge Object ID in the Fractal - Heap Header. -

-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
Fractal Heap ID for Huge Objects (sub-type 3): - directly accessed, non-filtered
bytebytebytebyte
Version & TypeThis space inserted - only to align table nicely

Address O
-

Length L
-
- - - - - - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
 (Items marked with an ‘L’ in the above table are - of the size specified in “Size of Lengths” field in the - superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version & Type

 -

This is a bit field with the following definition:

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

- -

Address

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

-

Length

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

-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Fractal Heap ID for Huge Objects (sub-type 4): - directly accessed, filtered
bytebytebytebyte
Version & TypeThis space inserted - only to align table nicely

Address O
-

Length L
-
Filter Mask

De-filtered Size L
-
- - - - - - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
 (Items marked with an ‘L’ in the above table are - of the size specified in “Size of Lengths” field in the - superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version & Type

 -

This is a bit field with the following definition:

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

- -

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.

-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - -
Fractal Heap ID for Managed Objects
bytebytebytebyte
Version & TypeThis space inserted - only to align table nicely
Offset (variable size)
Length (variable size)
-
- -
-
- - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version & Type

This is a bit field with the following definition:

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

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. -

-
- -
-

- III.G. Disk Format: Level 1G - - Free-space Manager -

- -

Free-space managers are used to describe space within a heap or - the entire HDF5 file that is not currently used for that heap or file. -

- -

- The free-space manager header contains metadata information - about the space being tracked, along with the address of the list of free - space sections which actually describes the free space. The header - records information about free-space sections being tracked, creation - parameters for handling free-space sections of a client, and section - information used to locate the collection of free-space sections. -

- -

- The free-space section list stores a collection of free-space - sections that is specific to each client of the free-space - manager. For example, the fractal heap is a client of the free space - manager and uses it to track unused space within the heap. There are 4 - types of section records for the fractal heap, each of which has its - own format, listed below. -

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Free-space Manager Header
bytebytebytebyte
Signature
VersionClient IDThis space inserted - only to align table nicely

Total Space TrackedL
-

Total Number of SectionsL
-

Number of Serialized SectionsL
-

Number of Un-Serialized SectionsL
-
Number of Section ClassesThis space inserted - only to align table nicely
Shrink PercentExpand Percent
Size of Address SpaceThis space inserted - only to align table nicely

Maximum Section Size L
-

Address of Serialized Section ListO
-

Size of Serialized Section List UsedL
-

Allocated Size of Serialized Section ListL
-
Checksum
- - - - - - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
 (Items marked with an ‘L’ in the above table are - of the size specified in “Size of Lengths” field in the - superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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:

- - - - - - - - - - - - - - - - - - -
IDDescription
0Fractal heap
1File
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 log2 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.

-
-
- -
-

- The free-space sections being managed are stored in a free-space - section list, described below. The sections in the free-space section - list are stored in the following way: a count of the number of sections - describing a particular size of free space and the size of the - free-space described (in bytes), followed by a list of section - description records; then another section count and size, followed by - the list of section descriptions for that size; and so on. -

- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Free-space Section List
bytebytebytebyte
Signature
VersionThis space inserted - only to align table nicely

Free-space Manager Header AddressO
-
Number of Section Records in Set #0 (variable - size)
Size of Free-space Section Described in Record - Set #0 (variable size) -
Record Set #0 Section Record #0 Offset(variable - size)
Record Set #0 Section Record #0 TypeThis space inserted - only to align table nicely
Record Set #0 Section Record #0 Data (variable - size)
...
Record Set #0 Section Record #K-1 Offset(variable - size)
Record Set #0 Section Record #K-1 TypeThis space inserted - only to align table nicely
Record Set #0 Section Record #K-1 Data (variable - size)
Number of Section Records in Set #1 (variable - size)
Size of Free-space Section Described in Record - Set #1 (variable size) -
Record Set #1 Section Record #0 Offset(variable - size)
Record Set #1 Section Record #0 TypeThis space inserted - only to align table nicely
Record Set #1 Section Record #0 Data (variable - size)
...
Record Set #1 Section Record #K-1 Offset(variable - size)
Record Set #1 Section Record #K-1 TypeThis space inserted - only to align table nicely
Record Set #1 Section Record #K-1 Data (variable - size)
...
...
Number of Section Records in Set #N-1 (variable - size)
Size of Free-space Section Described in Record - Set #N-1 (variable size) -
Record Set #N-1 Section Record #0 Offset(variable - size)
Record Set #N-1 Section Record #0 TypeThis space inserted - only to align table nicely
Record Set #N-1 Section Record #0 Data (variable - size)
...
Record Set #N-1 Section Record #K-1 Offset(variable - size)
Record Set #N-1 Section Record #K-1 TypeThis space inserted - only to align table nicely
Record Set #N-1 Section Record #K-1 Data (variable - size)
Checksum
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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: - -

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

- -

- The defined record types for a fractal heap client are: - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TypeDescription
0Fractal heap “single” section
1Fractal heap “first row” section
2Fractal heap “normal row” section
3Fractal 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. -

-
-
- -
-

The section-type specific data for each free-space section record - is described below:

- -
- - - - - - -
File’s Section Data Record
No additional record data stored
-
- -
-
-
- - - - - - -
Fractal Heap “Single” Section Data - Record
No additional record data stored
-
- -
-
-
- - - - - - -
Fractal Heap “First Row” Section Data - Record
Same format as “indirect” - section data
-
- -
-
-
- - - - - - -
Fractal Heap “Normal Row” Section Data - Record
No additional record data stored
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
Fractal Heap “Indirect” Section Data - Record
bytebytebytebyte
Fractal Heap Indirect Block Offset (variable - size)
Block Start RowBlock Start Column
Number of BlocksThis space inserted - only to align table nicely
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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.

-
-
- -
-

- III.H. Disk Format: Level 1H - Shared Object - Header Message Table -

- -

- The shared object header message table is used to locate - object header messages that are shared between two or more object - headers in the file. Shared object header messages are stored and - indexed in the file in one of two ways: indexed sequentially in a shared - header message list or indexed with a v2 B-tree. The shared messages - themselves are either stored in a fractal heap (when two or more - objects share the message), or remain in an object’s header (when - only one object uses the message currently, but the message can be - shared in the future). -

- -

- The shared object header message table contains a list of - shared message index headers. Each index header records information - about the version of the index format, the index storage type, flags - for the message types indexed, the number of messages in the index, the - address where the index resides, and the fractal heap address if shared - messages are stored there. -

- -

- Each index can be either a list or a v2 B-tree and may transition - between those two forms as the number of messages in the index varies. - Each shared message record contains information used to locate the - shared message from either a fractal heap or an object header. The - types of messages that can be shared are: Dataspace, Datatype, - Fill Value, Filter Pipeline and Attribute. -

- -

- The shared object header message table is pointed to from a shared message table message in the - superblock extension for a file. This message stores the version of the - table format, along with the number of index headers in the table. -

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Shared Object Header Message Table
bytebytebytebyte
Signature
Version for index #0Index Type for index #0Message Type Flags for index #0
Minimum Message Size for index #0
List Cutoff for index #0v2 B-tree Cutoff for index #0
Number of Messages for index #0This space inserted - only to align table nicely

Index AddressO for index #0
-

Fractal Heap AddressO for - index #0
-
...
...
Version for index #N-1Index Type for index #N-1Message Type Flags for index #N-1
Minimum Message Size for index #N-1
List Cutoff for index #N-1v2 B-tree Cutoff for index #N-1
Number of Messages for index #N-1This space inserted - only to align table nicely

Index AddressO for index #N-1
-

Fractal Heap AddressO for - index #N-1
-
Checksum
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BitsDescription
0If set, the index tracks Dataspace Messages. -
1If set, the message tracks Datatype Messages. -
2If set, the message tracks Fill Value Messages. -
3If set, the message tracks Filter Pipeline - Messages. -
4If set, the message tracks Attribute Messages. -
5-15Reserved (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.

-
-
- -
-

- Shared messages are indexed either with a shared message - record list, described below, or using a v2 B-tree (using record type - 7). The number of records in the shared message record list is - determined in the index’s entry in the shared object - header message table. -

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Shared Message Record List
bytebytebytebyte
Signature
Shared Message Record #0
Shared Message Record #1
...
Shared Message Record #N-1
Checksum
-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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.

-
-
- -
-

The record for each shared message in an index is stored in one - of the following forms:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - -
Shared Message Record, for messages stored in a - fractal heap
bytebytebytebyte
Message LocationThis space inserted - only to align table nicely
Hash Value
Reference Count

Fractal Heap ID
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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.

-
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Shared Message Record, for messages stored in an - object header
bytebytebytebyte
Message LocationThis space inserted - only to align table nicely
Hash Value
ReservedMessage TypeCreation Index

Object Header AddressO
-
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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.

-
-
- - - -
-
-
-

- IV. Disk Format: Level 2 - Data Objects -

- -

Data objects contain the “real” user-visible - information in the file. These objects compose the scientific data and - other information which are generally thought of as “data” - by the end-user. All the other information in the file is provided as a - framework for storing and accessing these data objects.

- -

A data object is composed of header and data information. The - header information contains the information needed to interpret the - data information for the object as well as additional - “metadata” or pointers to additional “metadata” - used to describe or annotate each object.

- -
-

- IV.A. Disk Format: Level 2A - Data Object - Headers -

- -

The header information of an object is designed to encompass all - of the information about an object, except for the data itself. This - information includes the dataspace, the datatype, information about how - the data is stored on disk (in external files, compressed, broken up in - blocks, and so on), as well as other information used by the library to - speed up access to the data objects or maintain a file’s - integrity. Information stored by user applications as attributes is - also stored in the object’s header. The header of each object is - not necessarily located immediately prior to the object’s data in - the file and in fact may be located in any position in the file. The - order of the messages in an object header is not significant.

- -

Object headers are composed of a prefix and a set of messages. - The prefix contains the information needed to interpret the messages - and a small amount of metadata about the object, and the messages - contain the majority of the metadata about the object.

- -
-

- IV.A.1. Disk Format: Level 2A1 - Data - Object Header Prefix -

- -
-

- IV.A.1.a. Version 1 Data Object - Header Prefix -

- -

Header messages are aligned on 8-byte boundaries for version 1 - object headers.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Version 1 Object Header
bytebytebytebyte
VersionReserved (zero)Total Number of Header Messages
Object Reference Count
Object Header Size
Header Message Type #1Size of Header Message Data #1
Header Message #1 FlagsReserved (zero)

Header Message Data #1
-
.
.
.
Header Message Type #nSize of Header Message Data #n
Header Message #n FlagsReserved (zero)

Header Message Data #n
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BitDescription
0If set, the message data is constant. This is used for - messages like the datatype message of a dataset.
1If 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. -
2If set, the message should not be shared.
3If 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) -
4If 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)
5If 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)
6If set, this message is shareable.
7If 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. -

-
-
- -
-

- IV.A.1.b. Version 2 Data Object - Header Prefix -

- -

Note that the “total number of messages” field has - been dropped from the data object header prefix in this version. The - number of messages in the data object header is just determined by the - messages encountered in all the object header blocks.

- -

- Note also that the fields and messages in this version of data object - headers have no alignment or padding bytes inserted - they are - stored packed together. -

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Version 2 Object Header
bytebytebytebyte
Signature
VersionFlagsThis space inserted - only to align table nicely
Access time (optional)
Modification Time (optional)
Change Time (optional)
Birth Time (optional)
Maximum # of compact attributes (optional)Minimum # of dense attributes (optional)
Size of Chunk #0 (variable size)This space inserted - only to align table nicely
Header Message Type #1Size of Header Message Data #1Header Message #1 Flags
Header Message #1 Creation Order (optional)This space inserted - only to align table nicely

Header Message Data #1
-
.
.
.
Header Message Type #nSize of Header Message Data #nHeader Message #n Flags
Header Message #n Creation Order (optional)This space inserted - only to align table nicely

Header Message Data #n
-
Gap (optional, variable size)
Checksum
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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-1This two bit field determines the size of the Size - of Chunk #0 field. The values are: - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0The Size of Chunk #0 field is 1 byte. -
1The Size of Chunk #0 field is 2 bytes. -
2The Size of Chunk #0 field is 4 bytes. -
3The Size of Chunk #0 field is 8 bytes. -
-

-
2If set, attribute creation order is tracked.
3If set, attribute creation order is indexed.
4If set, non-default attribute storage phase change values - are stored.
5If set, access, modification, change and birth times are - stored.
6-7Reserved
-

- -

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.

-
-
- -

The header message types and the message data associated with - them compose the critical “metadata” about each object. - Some header messages are required for each object while others are - optional. Some optional header messages may also be repeated several - times in the header itself, the requirements and number of times - allowed in the header will be noted in each header message description - below.

- - -
-

- IV.A.2. Disk Format: Level 2A2 - - Data Object Header Messages -

- -

Data object header messages are small pieces of metadata that are - stored in the data object header for each object in an HDF5 file. Data - object header messages provide the metadata required to describe an - object and its contents, as well as optional pieces of metadata that - annotate the meaning or purpose of the object.

- -

- Data object header messages are either stored directly in the data - object header for the object or are shared between multiple objects in - the file. When a message is shared, a flag in the Message - Flags indicates that the actual Message Data portion of that - message is stored in another location (such as another data object - header, or a heap in the file) and the Message Data field - contains the information needed to locate the actual information for - the message. -

- -

The format of shared message data is described here:

- -
- - - - - - - - - - - - - - - - - - - - - - - -
Shared Message (Version 1)
bytebytebytebyte
VersionTypeReserved (zero)
Reserved (zero)

AddressO
-
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

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

- - - - - - - - - - - - - - - -
VersionDescription
0Never used.
1Used by the library before version 1.6.1.
-

Type

The type of shared message location:

- - - - - - - - - - -
ValueDescription
0Message stored in another object’s header (a committed - message). -
-

Address

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

-
- -
-
-
- - - - - - - - - - - - - - - - - - - -
Shared Message (Version 2)
bytebytebytebyte
VersionTypeThis space inserted - only to align table nicely

AddressO
-
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
-
- -
-
- - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

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

- - - - - - - - - - -
VersionDescription
2Used by the library of version 1.6.1 and after.
-

Type

The type of shared message location:

- - - - - - - - - - -
ValueDescription
0Message stored in another object’s header (a committed - message). -
-

Address

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

-
- -
-
-
- - - - - - - - - - - - - - - - - - - -
Shared Message (Version 3)
bytebytebytebyte
VersionTypeThis space inserted - only to align table nicely
Location (variable size)
-
- -
-
- - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

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

- - - - - - - - - - -
VersionDescription
3Used 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:

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

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. -

-
- - -

The following is a list of currently defined header messages:

- -
-

- IV.A.2.a. The NIL Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: NIL
Header Message Type: 0x0000
Length: Varies
Status: Optional; may be repeated.
Description:The NIL message is used to indicate a message which is to be - ignored when reading the header messages for a data object. - [Possibly one which has been deleted for some reason.]
Format of Data: Unspecified
-
- - - -
-

- IV.A.2.b. The Dataspace Message -

- - -
- - - - - - - - - - - - - - - - - - - - - -
Header Message Name: Dataspace
Header Message Type: 0x0001
Length: Varies according to the number of - dimensions, as described in the following table.
Status: Required for dataset objects; may - not be repeated.
Description:The dataspace message describes the number of dimensions (in - other words, “rank”) and size of each dimension that the - data object has. This message is only used for datasets which have a - simple, rectilinear, array-like layout; datasets requiring a more - complex layout are not yet supported.
Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dataspace Message - Version 1
bytebytebytebyte
VersionDimensionalityFlagsReserved
Reserved

Dimension #1 SizeL
-
.
.
.

Dimension #n SizeL
-

Dimension #1 Maximum SizeL (optional)
-
.
.
.

Dimension #n Maximum SizeL (optional)
-

Permutation Index #1L (optional)
-
.
.
.

Permutation Index #nL (optional)
-
- - - - - - -
 (Items marked with an ‘L’ in the - above table are of the size specified in “Size of - Lengths” field in the superblock.)
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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 2 of the dataspace message dropped the optional - permutation index value support, as it was never implemented in the - HDF5 Library:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dataspace Message - Version 2
bytebytebytebyte
VersionDimensionalityFlagsType

Dimension #1 SizeL
-
.
.
.

Dimension #n SizeL
-

Dimension #1 Maximum SizeL (optional)
-
.
.
.

Dimension #n Maximum SizeL (optional)
-
- - - - - - -
 (Items marked with an ‘L’ in the - above table are of the size specified in “Size of - Lengths” field in the superblock.)
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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:

- - - - - - - - - - - - - - - - - - -
ValueDescription
0A scalar dataspace; in other words, a dataspace - with a single, dimensionless element. -
1A simple dataspace; in other words, a dataspace - with a rank > 0 and an appropriate # of dimensions. -
2A 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. -

-
-
- - - - - -
-

- IV.A.2.c. The Link Info Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Link Info
Header Message Type: 0x002
Length: Varies
Status: Optional; may not be repeated.
Description:The link info message tracks variable information about the - current state of the links for a “new style” - group’s behavior. Variable information will be stored in this - message and constant information will be stored in the Group Info message. -
Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Link Info
bytebytebytebyte
VersionFlagsThis space inserted - only to align table nicely

Maximum Creation Index (8 bytes, - optional)
-

Fractal Heap AddressO
-

Address of v2 B-tree for Name IndexO
-

Address of v2 B-tree for Creation Order - IndexO (optional)
-
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

 -

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

-

Flags

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

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

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. -

-
- - -
-

- IV.A.2.d. The Datatype Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Datatype
Header Message Type: 0x0003
Length: Variable
Status: Required for dataset or committed - datatype (formerly named datatype) objects; may not be repeated.
Description:

The datatype message defines the datatype for each - element of a dataset or a common datatype for sharing between - multiple datasets. A datatype can describe an atomic type like a - fixed- or floating-point type or more complex types like a C struct - (compound datatype), array (array datatype) or C++ vector - (variable-length datatype).

-

Datatype messages that are part of a dataset object do not - describe how elements are related to one another; the dataspace - message is used for that purpose. Datatype messages that are part - of a committed datatype (formerly named datatype) message describe - a common datatype that can be shared by multiple datasets in the - file.

Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - - - - - - - -
Datatype Message
bytebytebytebyte
Class and VersionClass Bit Field, Bits 0-7Class Bit Field, Bits 8-15Class Bit Field, Bits 16-23
Size

-
Properties
-
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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:

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

- -

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:

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

- -

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.

-
-
- - -
-

Class specific information for Fixed-Point Numbers (Class 0):

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Fixed-point Bit Field Description
BitsMeaning

0

- Byte Order. If zero, byte order is little-endian; otherwise, - byte order is big endian. -

1, 2

- Padding type. Bit 1 is the lo_pad bit and bit 2 is the - hi_pad bit. If a datum has unused bits at either end, then the - lo_pad or hi_pad bit is copied to those locations. -

3

- Signed. If this bit is set then the fixed-point number is in - 2’s complement form. -

4-23

Reserved (zero).

-
- -
-
- - - - - - - - - - - - - - -
Fixed-Point Property Description
ByteByteByteByte
Bit OffsetBit Precision
-
- -
-
- - - - - - - - - - - - - - - - -
Field NameDescription

Bit Offset

 -

The bit offset of the first significant bit of the - fixed-point value within the datatype. The bit offset specifies the - number of bits “to the right of” the value (which are - set to the lo_pad bit value).

-

Bit Precision

 -

The number of bits of precision of the fixed-point value - within the datatype. This value, combined with the datatype - element’s size and the Bit Offset field specifies the number - of bits “to the left of” the value (which are set to - the hi_pad bit value).

-
-
- - -
-

Class specific information for Floating-Point Numbers (Class 1):

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Floating-Point Bit Field Description
BitsMeaning

0, 6

- Byte Order. These two non-contiguous bits specify the - “endianness” of the bytes in the datatype element. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Bit 6Bit 0Description
00Byte order is little-endian
01Byte order is big-endian
10Reserved
11Byte order is VAX-endian
-

1, 2, 3

- Padding type. Bit 1 is the low bits pad type, bit 2 is the - high bits pad type, and bit 3 is the internal bits pad type. If a - datum has unused bits at either end or between the sign bit, - exponent, or mantissa, then the value of bit 1, 2, or 3 is copied - to those locations. -

4-5

- Mantissa Normalization. This 2-bit bit field specifies how - the most significant bit of the mantissa is managed. -

- - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0No normalization
1The most significant bit of the mantissa is always set - (except for 0.0).
2The most significant bit of the mantissa is not stored, - but is implied to be set.
3Reserved.
-

7

Reserved (zero).

8-15

- Sign Location. This is the bit position of the sign bit. - Bits are numbered with the least significant bit zero. -

16-23

Reserved (zero).

-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
Floating-Point Property Description
ByteByteByteByte
Bit OffsetBit Precision
Exponent LocationExponent SizeMantissa LocationMantissa Size
Exponent Bias
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Bit Offset

 -

The bit offset of the first significant bit of the - floating-point value within the datatype. The bit offset specifies - the number of bits “to the right of” the value.

-

Bit Precision

 -

The number of bits of precision of the floating-point value - within the datatype.

-

Exponent Location

 -

The bit position of the exponent field. Bits are numbered - with the least significant bit number zero.

-

Exponent Size

 -

The size of the exponent field in bits.

-

Mantissa Location

 -

The bit position of the mantissa field. Bits are numbered - with the least significant bit number zero.

-

Mantissa Size

 -

The size of the mantissa field in bits.

-

Exponent Bias

 -

The bias of the exponent field.

-
-
- - -
-

Class specific information for Time (Class 2):

- - -
- - - - - - - - - - - - - - - - - -
Time Bit Field Description
BitsMeaning

0

- Byte Order. If zero, byte order is little-endian; otherwise, - byte order is big endian. -

1-23

Reserved (zero).

-
- -
-
- - - - - - - - - - - -
Time Property Description
ByteByte
Bit Precision
-
- -
-
- - - - - - - - - - - -
Field NameDescription

Bit Precision

 -

The number of bits of precision of the time value.

-
-
- - -
-

Class specific information for Strings (Class 3):

- - -
- - - - - - - - - - - - - - - - - - - - - - -
String Bit Field Description
BitsMeaning

0-3

- Padding type. This four-bit value determines the type of - padding to use for the string. The values are: - -

- - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Null Terminate: A zero byte marks the end of the string - and is guaranteed to be present after converting a long string to - a short string. When converting a short string to a long string - the value is padded with additional null characters as necessary. -
1Null Pad: Null characters are added to the end of the - value during conversions from short values to long values but - conversion in the opposite direction simply truncates the value. -
2Space Pad: Space characters are added to the end of the - value during conversions from short values to long values but - conversion in the opposite direction simply truncates the value. - This is the Fortran representation of the string.
3-15Reserved
-

4-7

- Character Set. The character set used to encode the string. -

- - - - - - - - - - - - - - - - - - - - -
ValueDescription
0ASCII character set encoding
1UTF-8 character set encoding
2-15Reserved
-

8-23

Reserved (zero).

-
- -

There are no properties defined for the string class.

- - -

Class specific information for bit fields (Class 4):

- -
- - - - - - - - - - - - - - - - - - - - - - -
Bitfield Bit Field Description
BitsMeaning

0

- Byte Order. If zero, byte order is little-endian; otherwise, - byte order is big endian. -

1, 2

- Padding type. Bit 1 is the lo_pad type and bit 2 is the - hi_pad type. If a datum has unused bits at either end, then the - lo_pad or hi_pad bit is copied to those locations. -

3-23

Reserved (zero).

-
- -
-
- - - - - - - - - - - - - - -
Bit Field Property Description
ByteByteByteByte
Bit OffsetBit Precision
-
- -
-
- - - - - - - - - - - - - - - -
Field NameDescription

Bit Offset

 -

The bit offset of the first significant bit of the bit field - within the datatype. The bit offset specifies the number of bits - “to the right of” the value.

-

Bit Precision

 -

The number of bits of precision of the bit field within the - datatype.

-
-
- - -
-

Class specific information for Opaque (Class 5):

- -
- - - - - - - - - - - - - - - - - -
Opaque Bit Field Description
BitsMeaning

0-7

Length of ASCII tag in bytes.

8-23

Reserved (zero).

-
- -
-
- - - - - - - - - - - - - -
Opaque Property Description
ByteByteByteByte

ASCII Tag

-
- -
-
- - - - - - - - - - -
Field NameDescription

ASCII Tag

 -

This NUL-terminated string provides a description for the - opaque type. It is NUL-padded to a multiple of 8 bytes.

-
-
- - -
-

Class specific information for Compound (Class 6):

- -
- - - - - - - - - - - - - - - - - -
Compound Bit Field Description
BitsMeaning

0-15

- Number of Members. This field contains the number of members - defined for the compound datatype. The member definitions are - listed in the Properties field of the data type message. -

16-23

Reserved (zero).

-
- - -

The Properties field of a compound datatype is a list of the - member definitions of the compound datatype. The member definitions - appear one after another with no intervening bytes. The member types - are described with a (recursively) encoded datatype message.

- -

Note that the property descriptions are different for different - versions of the datatype version. Additionally note that the version 0 - datatype encoding is deprecated and has been replaced with later - encodings in versions of the HDF5 Library from the 1.4 release onward.

- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Compound Properties Description for Datatype - Version 1
ByteByteByteByte

Name
-
Byte Offset of Member
DimensionalityReserved (zero)
Dimension Permutation
Reserved (zero)
Dimension #1 Size (required)
Dimension #2 Size (required)
Dimension #3 Size (required)
Dimension #4 Size (required)

Member Type Message
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Name

 -

This NUL-terminated string provides a description for the - opaque type. It is NUL-padded to a multiple of 8 bytes.

-

Byte Offset of Member

 -

This is the byte offset of the member within the datatype.

-

Dimensionality

 -

If set to zero, this field indicates a scalar member. If set - to a value greater than zero, this field indicates that the member - is an array of values. For array members, the size of the array is - indicated by the ‘Size of Dimension n’ field in this - message.

-

Dimension Permutation

 -

This field was intended to allow an array field to have its - dimensions permuted, but this was never implemented. This field - should always be set to zero.

-

Dimension #n Size

 -

This field is the size of a dimension of the array field 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.

-

Member Type Message

 -

This field is a datatype message describing the datatype of - the member.

-
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - -
Compound Properties Description for Datatype - Version 2
ByteByteByteByte

Name
-
Byte Offset of Member

Member Type Message
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Name

 -

This NUL-terminated string provides a description for the - opaque type. It is NUL-padded to a multiple of 8 bytes.

-

Byte Offset of Member

 -

This is the byte offset of the member within the datatype.

-

Member Type Message

 -

This field is a datatype message describing the datatype of - the member.

-
-
- - -
-
-
- - - - - - - - - - - - - - - - - - - - - - -
Compound Properties Description for Datatype - Version 3
ByteByteByteByte

Name
-
Byte Offset of Member (variable size)

Member Type Message
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Name

- This NUL-terminated string provides a description for the opaque - type. It is not NUL-padded to a multiple of 8 bytes. -

Byte Offset of Member

This is the byte offset of the member within the - datatype. The field size is the minimum number of bytes necessary, - based on the size of the datatype element. For example, a datatype - element size of less than 256 bytes uses a 1 byte length, a - datatype element size of 256-65535 bytes uses a 2 byte length, and - so on.

Member Type Message

This field is a datatype message describing the - datatype of the member.

-
- - -
-

Class specific information for Reference (Class 7):

- -
- - - - - - - - - - - - - - - - - -
Reference Bit Field Description
BitsMeaning

0-3

- Type. This four-bit value contains the type of reference - described. The values defined are: - -

- - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Object Reference: A reference to another object in this - HDF5 file.
1Dataset Region Reference: A reference to a region within - a dataset in this HDF5 file.
2-15Reserved
-

4-23

Reserved (zero).

-
- -

There are no properties defined for the reference class.

- - -
-

Class specific information for Enumeration (Class 8):

- -
- - - - - - - - - - - - - - - - - -
Enumeration Bit Field Description
BitsMeaning

0-15

- Number of Members. The number of name/value pairs defined - for the enumeration type. -

16-23

Reserved (zero).

-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - -
Enumeration Property Description for Datatype - Versions 1 & 2
ByteByteByteByte

Base Type
-

Names
-

Values
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Base Type

 -

Each enumeration type is based on some parent type, usually - an integer. The information for that parent type is described - recursively by this field.

-

Names

 -

The name for each name/value pair. Each name is stored as a - null terminated ASCII string in a multiple of eight bytes. The - names are in no particular order.

-

Values

 -

The list of values in the same order as the names. The values - are packed (no inter-value padding) and the size of each value is - determined by the parent type.

-
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - -
Enumeration Property Description for Datatype - Version 3
ByteByteByteByte

Base Type
-

Names
-

Values
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Base Type

 -

Each enumeration type is based on some parent type, usually - an integer. The information for that parent type is described - recursively by this field.

-

Names

 -

- The name for each name/value pair. Each name is stored as a null - terminated ASCII string, not padded to a multiple of eight - bytes. The names are in no particular order. -

-

Values

 -

The list of values in the same order as the names. The values - are packed (no inter-value padding) and the size of each value is - determined by the parent type.

-
-
- - - -
-

Class specific information for Variable-Length (Class 9):

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Variable-Length Bit Field Description
BitsMeaning

0-3

- Type. This four-bit value contains the type of - variable-length datatype described. The values defined are: - -

- - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Sequence: A variable-length sequence of any datatype. - Variable-length sequences do not have padding or character set - information.
1String: A variable-length sequence of characters. - Variable-length strings have padding and character set - information.
2-15Reserved
-

4-7

- Padding type. (variable-length string only) This four-bit - value determines the type of padding used for variable-length - strings. The values are the same as for the string padding type, as - follows: -

- - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Null terminate: A zero byte marks the end of a string and - is guaranteed to be present after converting a long string to a - short string. When converting a short string to a long string, - the value is padded with additional null characters as necessary. -
1Null pad: Null characters are added to the end of the - value during conversion from a short string to a longer string. - Conversion from a long string to a shorter string simply - truncates the value.
2Space pad: Space characters are added to the end of the - value during conversion from a short string to a longer string. - Conversion from a long string to a shorter string simply - truncates the value. This is the Fortran representation of the - string.
3-15Reserved
-

- -

This value is set to zero for variable-length sequences.

8-11

- Character Set. (variable-length string only) This four-bit - value specifies the character set to be used for encoding the - string: -

- - - - - - - - - - - - - - - - - - - - -
ValueDescription
0ASCII character set encoding
1UTF-8 character set encoding
2-15Reserved
-

- -

This value is set to zero for variable-length sequences.

12-23

Reserved (zero).

-
- -
-
-
- - - - - - - - - - - - - - -
Variable-Length Property Description
ByteByteByteByte

Base Type
-
-
- -
-
- - - - - - - - - - - -
Field NameDescription

Base Type

 -

Each variable-length type is based on some parent type. The - information for that parent type is described recursively by this - field.

-
-
- - -
-

Class specific information for Array (Class 10):

- -

There are no bit fields defined for the array class.

- -

Note that the dimension information defined in the property for - this datatype class is independent of dataspace information for a - dataset. The dimension information here describes the dimensionality of - the information within a data element (or a component of an element, if - the array datatype is nested within another datatype) and the dataspace - for a dataset describes the size and locations of the elements in a - dataset.

- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Array Property Description for Datatype Version 2
ByteByteByteByte
DimensionalityReserved (zero)
Dimension #1 Size
.
.
.
Dimension #n Size
Permutation Index #1
.
.
.
Permutation Index #n

Base Type
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Dimensionality

 -

This value is the number of dimensions that the array has.

-

Dimension #n Size

 -

This value is the size of the dimension of the array 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.

-

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. Currently, dimension permutations are not - supported, and these indices should be set to the index position - minus one. In other words, the first dimension should be set to 0, - the second dimension should be set to 1, and so on.

-

Base Type

 -

Each array type is based on some parent type. The information - for that parent type is described recursively by this field.

-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Array Property Description for Datatype Version 3
ByteByteByteByte
DimensionalityThis space inserted - only to align table nicely
Dimension #1 Size
.
.
.
Dimension #n Size

Base Type
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Dimensionality

 -

This value is the number of dimensions that the array has.

-

Dimension #n Size

 -

This value is the size of the dimension of the array 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.

-

Base Type

 -

Each array type is based on some parent type. The information - for that parent type is described recursively by this field.

-
-
- - - -
-

- IV.A.2.e. The Data Storage - Fill - Value (Old) Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Fill Value (old)
Header Message Type: 0x0004
Length: Varies
Status: Optional; may not be repeated.
Description:

The fill value message stores a single data value - which is returned to the application when an uninitialized data - element is read from a dataset. The fill value is interpreted with - the same datatype as the dataset. If no fill value message is - present then a fill value of all zero bytes is assumed.

-

This fill value message is deprecated in favor of the - “new” fill value message (Message Type 0x0005) and is - only written to the file for forward compatibility with versions of - the HDF5 Library before the 1.6.0 version. Additionally, it only - appears for datasets with a user-defined fill value (as opposed to - the library default fill value or an explicitly set - “undefined” fill value).

Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - -
Fill Value Message (Old)
bytebytebytebyte
Size

Fill Value (optional, variable - size)
-
-
- -
-
- - - - - - - - - - - - - - - -
Field NameDescription

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.

-
-
- - -
-

- IV.A.2.f. The Data Storage - Fill Value - Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Fill Value
Header Message Type: 0x0005
Length: Varies
Status: Required for dataset objects; may - not be repeated.
Description:The fill value message stores a single data value which is - returned to the application when an uninitialized data element is - read from a dataset. The fill value is interpreted with the same - datatype as the dataset.
Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - - - - - - - -
Fill Value Message - Versions 1 & 2
bytebytebytebyte
VersionSpace Allocation TimeFill Value Write TimeFill Value Defined
Size (optional)

Fill Value (optional, variable - size)
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

 -

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

- - - - - - - - - - - - - - - - - - - - - - -
VersionDescription
0Never used
1Initial version of this message.
2In this version, the Size and Fill Value fields are only - present if the Fill Value Defined field is set to 1.
3This 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:

- - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Not used.
1Early allocation. Storage space for the entire dataset - should be allocated in the file when the dataset is created.
2Late allocation. Storage space for the entire dataset - should not be allocated until the dataset is written to.
3Incremental 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:

- - - - - - - - - - - - - - - - - - -
ValueDescription
0On allocation. The fill value is always written to the - raw data storage when the storage space is allocated.
1Never. The fill value should never be written to the raw - data storage.
2Fill 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.

-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - -
Fill Value Message - Version 3
bytebytebytebyte
VersionFlagsThis space inserted - only to align table nicely
Size (optional)

Fill Value (optional, variable - size)
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

 -

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

- - - - - - - - - - - - - - - - - - - - - - -
VersionDescription
0Never used
1Initial version of this message.
2In this version, the Size and Fill Value fields are only - present if the Fill Value Defined field is set to 1.
3This 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:

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

-
-
- - -
-

- IV.A.2.g. The Link Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Link
Header Message Type: 0x0006
Length: Varies
Status: Optional; may be repeated.
Description:

This message encodes the information for a link in a - group’s object header, when the group is storing its links - “compactly”, or in the group’s fractal heap, when - the group is storing its links “densely”.

-

- A group is storing its links compactly when the fractal heap - address in the Link Info - Message is set to the “undefined address” value. -

Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Link Message
bytebytebytebyte
VersionFlagsLink type (optional)This space inserted only to align - table nicely

Creation Order (8 bytes, - optional)
-
Link Name Character Set (optional)Length of Link Name (variable size)This space inserted - only to align table nicely
Link Name (variable size)

Link Information (variable size)
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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.

- - - - - - - - - - - - - - - - - - - - - - - - - - -
BitsDescription
0-1Determines the size of the Length of Link Name - field. - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0The size of the Length of Link Name field is - 1 byte. -
1The size of the Length of Link Name field is - 2 bytes. -
2The size of the Length of Link Name field is - 4 bytes. -
3The size of the Length of Link Name field is - 8 bytes. -
-
2Creation 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. -
3Link 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. -
4Link 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-7Reserved (zero).
-

Link type

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

- - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0A hard link (should never be stored in the file)
1A soft link.
2-63Reserved for future HDF5 internal use.
64An external link.
65-255Reserved, 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:

- - - - - - - - - - - - - - - -
ValueDescription
0ASCII character set encoding (this should never be stored - in the file)
1UTF-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.
-

-
- -
-

- IV.A.2.h. The Data Storage - - External Data Files Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: External Data Files
Header Message Type: 0x0007
Length: Varies
Status: Optional; may not be repeated.
Description:The external data storage message indicates that the data - for an object is stored outside the HDF5 file. The filename of the - object is stored as a Universal Resource Location (URL) of the - actual filename containing the data. An external file list record - also contains the byte offset of the start of the data within the - file and the amount of space reserved in the file for that data.
Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
External File List Message
bytebytebytebyte
VersionReserved (zero)
Allocated SlotsUsed Slots

Heap AddressO
-

Slot Definitions...
-
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

 -

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

- - - - - - - - - - - - - -
VersionDescription
0Never used.
1The 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.

-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
External File List Slot
bytebytebytebyte

Name Offset in Local HeapL
-

Offset in External Data FileL
-

Data Size in External FileL
-
- - - - - - -
 (Items marked with an ‘L’ in the - above table are of the size specified in “Size of - Lengths” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - -
Field NameDescription

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.

-
-
- - -
-

- IV.A.2.i. The Data Storage - Layout Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Data Storage - - Layout
Header Message Type: 0x0008
Length: Varies
Status: Required for datasets; may not be - repeated.
Description:Data layout describes how the elements of a - multi-dimensional array are stored in the HDF5 file. Three types of - data layout are supported: -
    -
  1. Contiguous: The array is stored in one contiguous area of - the file. This layout requires that the size of the array be - constant: data manipulations such as chunking, compression, - checksums, or encryption are not permitted. The message stores the - total storage size of the array. The offset of an element from the - beginning of the storage area is computed as in a C array.
    2. -
  2. Chunked: The array domain is regularly decomposed into - chunks, and each chunk is allocated and stored separately. This - layout supports arbitrary element traversals, compression, - encryption, and checksums. (these features are described in other - messages). The message stores the size of a chunk instead of the - size of the entire array; the storage size of the entire array can - be calculated by traversing the B-tree that stores the chunk - addresses.
    3. -
  3. Compact: The array is stored in one contiguous block, as - part of this object header message.
    4. -
-
Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Data Layout Message (Versions 1 and 2)
bytebytebytebyte
VersionDimensionalityLayout ClassReserved (zero)
Reserved (zero)

Data AddressO (optional)
-
Dimension 0 Size
Dimension 1 Size
...
Dimension #n Size
Dataset Element Size (optional)
Compact Data Size (optional)

Compact Data... (variable size, - optional)
-
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

 -

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

- - - - - - - - - - - - - - - - - - - - -
VersionDescription
0Never used.
1Used by version 1.4 and before of the library to encode - layout information. Data space is always allocated when the data - set is created.
2Used by version 1.6.x of the library to encode layout - information. Data space is allocated only when it is necessary.
-

-

Dimensionality

An array has a fixed dimensionality. This field - specifies the number of dimension size fields later in the message. - The value stored for chunked storage is 1 greater than the number - of dimensions in the dataset’s dataspace. For example, 2 is - stored for a 1 dimensional dataset.

Layout Class

The layout class specifies the type of storage for - the data and how the other fields of the layout message are to be - interpreted.

- - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Compact Storage
1Contiguous Storage
2Chunked Storage
-

Data Address

For contiguous storage, this is the address of the - raw data in the file. For chunked storage this is the address of - the v1 B-tree that is used to look up the addresses of the chunks. - This field is not present for compact storage. If the version for - this message is greater than 1, the address may have the - “undefined address” value, to indicate that storage has - not yet been allocated for this array.

Dimension #n Size

For contiguous and compact storage the dimensions - define the entire size of the array while for chunked storage they - define the size of a single chunk. In all cases, they are in units - of array elements (not bytes). The first dimension stored in the - list of dimensions is the slowest changing dimension and the last - dimension stored is the fastest changing dimension.

Dataset Element Size

The size of a dataset element, in bytes. This field - is only present for chunked storage.

Compact Data Size

This field is only present for compact data storage. - It contains the size of the raw data for the dataset array, in - bytes.

Compact Data

This field is only present for compact data storage. - It contains the raw data for the dataset array.

-
- -
-

Version 3 of this message re-structured the format into specific - properties that are required for each layout class.

- - -
- - - - - - - - - - - - - - - - - - - -
- Data Layout Message (Version 3) -
bytebytebytebyte
VersionLayout ClassThis space inserted - only to align table nicely

Properties (variable size)
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

 -

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

- - - - - - - - - - -
VersionDescription
3Used by the version 1.6.3 and later of the library to - store properties for each layout class.
-

-

Layout Class

The layout class specifies the type of storage for - the data and how the other fields of the layout message are to be - interpreted.

- - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Compact Storage
1Contiguous Storage
2Chunked Storage
-

Properties

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

-
- -
-

Class-specific information for compact layout (Class 0): (Note: - The dimensionality information is in the Dataspace message)

- - -
- - - - - - - - - - - - - - - - - - -
Compact Storage Property Description
bytebytebytebyte
SizeThis space inserted - only to align table nicely

Raw Data... (variable size)
-
-
- -
-
- - - - - - - - - - - - - - - -
Field NameDescription

Size

This field contains the size of the raw data for the - dataset array, in bytes.

Raw Data

This field contains the raw data for the dataset - array.

-
- - -
-

Class-specific information for contiguous layout (Class 1): - (Note: The dimensionality information is in the Dataspace message)

- - -
- - - - - - - - - - - - - - - - - -
Contiguous Storage Property Description
bytebytebytebyte

AddressO
-

SizeL
-
- - - - - - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
 (Items marked with an ‘L’ in the above table are - of the size specified in “Size of Lengths” field in the - superblock.)
- -
- -
-
- - - - - - - - - - - - - - - -
Field NameDescription

Address

This is the address of the raw data in the file. The - address may have the “undefined address” value, to - indicate that storage has not yet been allocated for this array.

Size

This field contains the size allocated to store the - raw data, in bytes.

-
- - -
-

Class-specific information for chunked layout (Class 2):

- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Chunked Storage Property Description
bytebytebytebyte
DimensionalityThis space inserted - only to align table nicely

AddressO
-
Dimension 0 Size
Dimension 1 Size
...
Dimension #n Size
Dataset Element Size
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Dimensionality

A chunk has a fixed dimensionality. This field - specifies the number of dimension size fields later in the message.

Address

This is the address of the v1 B-tree that is used to - look up the addresses of the chunks that actually store portions of - the array data. The address may have the “undefined - address” value, to indicate that storage has not yet been - allocated for this array.

Dimension #n Size

These values define the dimension size of a single - chunk, in units of array elements (not bytes). The first dimension - stored in the list of dimensions is the slowest changing dimension - and the last dimension stored is the fastest changing dimension.

Dataset Element Size

The size of a dataset element, in bytes.

-
- -
-

- IV.A.2.j. The Bogus Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Bogus
Header Message Type: 0x0009
Length: 4 bytes
Status: For testing only; should never be - stored in a valid file.
Description:This message is used for testing the HDF5 Library’s - response to an “unknown” message type and should never - be encountered in a valid HDF5 file.
Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - -
Bogus Message
bytebytebytebyte
Bogus Value
-
- -
-
- - - - - - - - - - -
Field NameDescription

Bogus Value

 -

- This value should always be: - 0xdeadbeef - . -

-
-
- -
-

- IV.A.2.k. The Group Info Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Group Info
Header Message Type: 0x000A
Length: Varies
Status: Optional; may not be repeated.
Description:

- This message stores information for the constants defining a - “new style” group’s behavior. Constant - information will be stored in this message and variable information - will be stored in the Link Info - message. -

-

Note: the “estimated entry” information below is - used when determining the size of the object header for the group - when it is created.

Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - - - - - - - -
Group Info Message
bytebytebytebyte
VersionFlagsLink Phase Change: Maximum Compact Value (optional)
Link Phase Change: Minimum Dense Value (optional)Estimated Number of Entries (optional)
Estimated Link Name Length of Entries (optional)This space inserted - only to align table nicely
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

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

Flags

This is the group information flag with the following - definition:

- - - - - - - - - - - - - - - - - - -
BitDescription
0If set, link phase change values are stored.
1If set, the estimated entry information is non-default - and is stored.
2-7Reserved
-

Link Phase Change: Maximum Compact Value

The is the maximum number of links to store - “compactly” (in the group’s object header).

-

- This field is present if bit 0 of Flags is set. -

Link Phase Change: Minimum Dense Value

- This is the minimum number of links to store “densely” - (in the group’s fractal heap). The fractal heap’s - address is located in the Link Info - message. -

-

- This field is present if bit 0 of Flags is set. -

Estimated Number of Entries

This is the estimated number of entries in groups.

-

- If this field is not present, the default value of - 4 - will be used for the estimated number of group entries. -

-

- This field is present if bit 1 of Flags is set. -

Estimated Link Name Length of Entries

This is the estimated length of entry name.

-

- If this field is not present, the default value of - 8 - will be used for the estimated link name length of group entries. -

-

- This field is present if bit 1 of Flags is set. -

-
-

- -
-

- IV.A.2.l. The Data Storage - Filter - Pipeline Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Data Storage - - Filter Pipeline
Header Message Type: 0x000B
Length: Varies
Status: Optional; may not be repeated.
Description:

This message describes the filter pipeline which - should be applied to the data stream by providing filter - identification numbers, flags, a name, and client data.

-

This message may be present in the object headers of both - dataset and group objects. For datasets, it specifies the filters - to apply to raw data. For groups, it specifies the filters to apply - to the group’s fractal heap. Currently, only datasets using - chunked data storage use the filter pipeline on their raw data.

Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - - - - - - -
Filter Pipeline Message - Version 1
bytebytebytebyte
VersionNumber of FiltersReserved (zero)
Reserved (zero)

Filter Description List (variable - size)
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

The version number for this message. This table - describes version 1.

Number of Filters

The total number of filters described in this - message. The maximum possible number of filters in a message is 32.

Filter Description List

A description of each filter. A filter description - appears in the next table.

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Filter Description
bytebytebytebyte
Filter Identification ValueName Length
FlagsNumber Client Data Values

Name (variable size, optional)
-

Client Data (variable size, - optional)
-
Padding (variable size, optional)
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Filter Identification Value

 -

- This value, often referred to as a filter identifier, is designed - to be a unique identifier for the filter. Values from zero through - 32,767 are reserved for filters supported by The HDF Group in the - HDF5 Library and for filters requested and supported by third - parties. Filters supported by The HDF Group are documented - immediately below. Information on 3rd-party filters can be found at - The HDF Group’s - Registered Filters page. -

- -

- To request a filter identifier, please contact The HDF - Group’s Help Desk at The HDF Group Help Desk. - You will be asked to provide the following information: -

-
    -
  1. Contact information for the developer requesting the new - identifier
    2. -
  2. A short description of the new filter
    3. -
  3. Links to any relevant information, including licensing - information
    4. -
-

Values from 32768 to 65535 are reserved for non-distributed - uses (for example, internal company usage) or for application usage - when testing a feature. The HDF Group does not track or document - the use of the filters with identifiers from this range.

- -

The filters currently in library version 1.8.0 are listed - below:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IdentificationNameDescription
0N/AReserved
1deflateGZIP deflate compression
2shuffleData element shuffling
3fletcher32Fletcher32 checksum
4szipSZIP compression
5nbitN-bit packing
6scaleoffsetScale and offset encoded values
-

-

Name Length

Each filter has an optional null-terminated ASCII - name and this field holds the length of the name including the null - termination padded with nulls to be a multiple of eight. If the - filter has no name then a value of zero is stored in this field.

Flags

The flags indicate certain properties for a filter. - The bit values defined so far are:

- - - - - - - - - - - - - - - -
BitDescription
0If set then the filter is an optional filter. During - output, if an optional filter fails it will be silently skipped - in the pipeline.
1-15Reserved (zero)
-

Number of Client Data Values

- Each filter can store integer values to control how the filter - operates. The number of entries in the Client Data array - is stored in this field. -

Name

- If the Name Length field is non-zero then it will contain - the size of this field, padded to a multiple of eight. This field - contains a null-terminated, ASCII character string to serve as a - comment/name for the filter. -

Client Data

- This is an array of four-byte integers which will be passed to the - filter function. The Client Data Number of Values - determines the number of elements in the array. -

Padding

Four bytes of zeroes are added to the message at this - point if the Client Data Number of Values field contains an odd - number.

-
- -
-
- - - - - - - - - - - - - - - - - - - -
Filter Pipeline Message - Version 2
bytebytebytebyte
VersionNumber of FiltersThis space inserted - only to align table nicely

Filter Description List (variable - size)
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

The version number for this message. This table - describes version 2.

Number of Filters

The total number of filters described in this - message. The maximum possible number of filters in a message is 32.

Filter Description List

A description of each filter. A filter description - appears in the next table.

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Filter Description
bytebytebytebyte
Filter Identification ValueName Length (optional)
FlagsNumber Client Data Values

Name (variable size, optional)
-

Client Data (variable size, - optional)
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Filter Identification Value

 -

- This value, often referred to as a filter identifier, is designed - to be a unique identifier for the filter. Values from zero through - 32,767 are reserved for filters supported by The HDF Group in the - HDF5 Library and for filters requested and supported by third - parties. Filters supported by The HDF Group are documented - immediately below. Information on 3rd-party filters can be found at - The HDF Group’s - Registered Filters page. -

- -

- To request a filter identifier, please contact The HDF - Group’s Help Desk at The HDF Group Help Desk. - You will be asked to provide the following information: -

-
    -
  1. Contact information for the developer requesting the new - identifier
    2. -
  2. A short description of the new filter
    3. -
  3. Links to any relevant information, including licensing - information
    4. -
-

Values from 32768 to 65535 are reserved for non-distributed - uses (for example, internal company usage) or for application usage - when testing a feature. The HDF Group does not track or document - the use of the filters with identifiers from this range.

- -

The filters currently in library version 1.8.0 are listed - below:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IdentificationNameDescription
0N/AReserved
1deflateGZIP deflate compression
2shuffleData element shuffling
3fletcher32Fletcher32 checksum
4szipSZIP compression
5nbitN-bit packing
6scaleoffsetScale and offset encoded values
-

-

Name Length

Each filter has an optional null-terminated ASCII - name and this field holds the length of the name including the null - termination padded with nulls to be a multiple of eight. If the - filter has no name then a value of zero is stored in this field.

-

- Filters with IDs less than 256 (in other words, filters that are - defined in this format documentation) do not store the Name - Length or Name fields. -

Flags

The flags indicate certain properties for a filter. - The bit values defined so far are:

- - - - - - - - - - - - - - - -
BitDescription
0If set then the filter is an optional filter. During - output, if an optional filter fails it will be silently skipped - in the pipeline.
1-15Reserved (zero)
-

Number of Client Data Values

- Each filter can store integer values to control how the filter - operates. The number of entries in the Client Data array - is stored in this field. -

Name

- If the Name Length field is non-zero then it will contain - the size of this field, not padded to a multiple of eight. - This field contains a non-null-terminated, ASCII character - string to serve as a comment/name for the filter. -

-

- Filters that are defined in this format documentation such as - deflate and shuffle do not store the Name Length or Name - fields. -

Client Data

- This is an array of four-byte integers which will be passed to the - filter function. The Client Data Number of Values - determines the number of elements in the array. -

-
- -
-

- IV.A.2.m. The Attribute Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Attribute
Header Message Type: 0x000C
Length: Varies
Status: Optional; may be repeated.
Description:

- The Attribute message is used to store objects in the HDF5 - file which are used as attributes, or “metadata” about - the current object. An attribute is a small dataset; it has a name, - a datatype, a dataspace, and raw data. Since attributes are stored - in the object header, they should be relatively small (in other - words, less than 64KB). They can be associated with any type of - object which has an object header (groups, datasets, or committed - (named) datatypes). -

-

- In 1.8.x versions of the library, attributes can be larger than - 64KB. See the - “Special Issues” section of the Attributes chapter in - the HDF5 User Guide for more information. -

-

Note: Attributes on an object must have unique names: the - HDF5 Library currently enforces this by causing the creation of an - attribute with a duplicate name to fail. Attributes on different - objects may have the same name, however.

Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Attribute Message (Version 1)
bytebytebytebyte
VersionReserved (zero)Name Size
Datatype SizeDataspace Size

Name (variable size)
-

Datatype (variable size)
-

Dataspace (variable size)
-

Data (variable size)
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

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

- - - - - - - - - - - - - - - -
VersionDescription
0Never used.
1Used by the library before version 1.6 to encode - attribute message. This version does not support shared - datatypes.
-

Name Size

- The length of the attribute name in bytes including the null - terminator. Note that the Name field below may contain - additional padding not represented by this field. -

Datatype Size

- The length of the datatype description in the Datatype - field below. Note that the Datatype field may contain - additional padding not represented by this field. -

Dataspace Size

- The length of the dataspace description in the Dataspace - field below. Note that the Dataspace field may contain - additional padding not represented by this field. -

Name

The null-terminated attribute name. This field is - padded with additional null characters to make it a multiple of - eight bytes.

Datatype

The datatype description follows the same format as - described for the datatype object header message. This field is - padded with additional zero bytes to make it a multiple of eight - bytes.

Dataspace

The dataspace description follows the same format as - described for the dataspace object header message. This field is - padded with additional zero bytes to make it a multiple of eight - bytes.

Data

- The raw data for the attribute. The size is determined from the - datatype and dataspace descriptions. This field is not - padded with additional bytes. -

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Attribute Message (Version 2)
bytebytebytebyte
VersionFlagsName Size
Datatype SizeDataspace Size

Name (variable size)
-

Datatype (variable size)
-

Dataspace (variable size)
-

Data (variable size)
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

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

- - - - - - - - - - -
VersionDescription
2Used by the library of version 1.6.x and after to encode - attribute messages. This version supports shared datatypes. The - fields of name, datatype, and dataspace are not padded with - additional bytes of zero.
-

Flags

This bit field contains extra information about - interpreting the attribute message:

- - - - - - - - - - - - - - - -
BitDescription
0If set, datatype is shared.
1If set, dataspace is shared.
-

Name Size

The length of the attribute name in bytes including - the null terminator.

Datatype Size

- The length of the datatype description in the Datatype - field below. -

Dataspace Size

- The length of the dataspace description in the Dataspace - field below. -

Name

- The null-terminated attribute name. This field is not - padded with additional bytes. -

Datatype

The datatype description follows the same format as - described for the datatype object header message.

-

- If the Flag field indicates this attribute’s - datatype is shared, this field will contain a “shared - message” encoding instead of the datatype encoding. -

-

- This field is not padded with additional bytes. -

Dataspace

The dataspace description follows the same format as - described for the dataspace object header message.

-

- If the Flag field indicates this attribute’s - dataspace is shared, this field will contain a “shared - message” encoding instead of the dataspace encoding. -

-

- This field is not padded with additional bytes. -

Data

The raw data for the attribute. The size is - determined from the datatype and dataspace descriptions.

-

- This field is not padded with additional zero bytes. -

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Attribute Message (Version 3)
bytebytebytebyte
VersionFlagsName Size
Datatype SizeDataspace Size
Name Character Set EncodingThis space inserted - only to align table nicely

Name (variable size)
-

Datatype (variable size)
-

Dataspace (variable size)
-

Data (variable size)
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

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

- - - - - - - - - - -
VersionDescription
3Used by the library of version 1.8.x and after to encode - attribute messages. This version supports attributes with - non-ASCII names.
-

Flags

This bit field contains extra information about - interpreting the attribute message:

- - - - - - - - - - - - - - - -
BitDescription
0If set, datatype is shared.
1If set, dataspace is shared.
-

Name Size

The length of the attribute name in bytes including - the null terminator.

Datatype Size

- The length of the datatype description in the Datatype - field below. -

Dataspace Size

- The length of the dataspace description in the Dataspace - field below. -

Name Character Set Encoding

The character set encoding for the attribute’s - name:

- - - - - - - - - - - - - - - -
ValueDescription
0ASCII character set encoding
1UTF-8 character set encoding
-

Name

- The null-terminated attribute name. This field is not - padded with additional bytes. -

Datatype

The datatype description follows the same format as - described for the datatype object header message.

-

- If the Flag field indicates this attribute’s - datatype is shared, this field will contain a “shared - message” encoding instead of the datatype encoding. -

-

- This field is not padded with additional bytes. -

Dataspace

The dataspace description follows the same format as - described for the dataspace object header message.

-

- If the Flag field indicates this attribute’s - dataspace is shared, this field will contain a “shared - message” encoding instead of the dataspace encoding. -

-

- This field is not padded with additional bytes. -

Data

The raw data for the attribute. The size is - determined from the datatype and dataspace descriptions.

-

- This field is not padded with additional zero bytes. -

-
- -
-

- IV.A.2.n. The Object Comment Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Object Comment
Header Message Type: 0x000D
Length: Varies
Status: Optional; may not be repeated.
Description:The object comment is designed to be a short description of - an object. An object comment is a sequence of non-zero (\0) - ASCII characters with no other formatting included by the library. -
Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - -
Name Message
bytebytebytebyte

Comment (variable size)
-
-
- -
-
- - - - - - - - - - -
Field NameDescription

Name

A null terminated ASCII character string.

-
- -
-

- IV.A.2.o. The Object - Modification Time (Old) Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Object Modification - Time (Old)
Header Message Type: 0x000E
Length: Fixed
Status: Optional; may not be repeated.
Description:

The object modification date and time is a timestamp - which indicates (using ISO-8601 date and time format) the last - modification of an object. The time is updated when any object - header message changes according to the system clock where the - change was posted. All fields of this message should be interpreted - as coordinated universal time (UTC).

-

- This modification time message is deprecated in favor of the - “new” Object - Modification Time message and is no longer written to the file in - versions of the HDF5 Library after the 1.6.0 version. -

Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Modification Time Message
bytebytebytebyte
Year
MonthDay of Month
HourMinute
SecondReserved
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Year

- The four-digit year as an ASCII string. For example, - 1998 - . -

Month

- The month number as a two digit ASCII string where January is - 01 - and December is - 12 - . -

Day of Month

- The day number within the month as a two digit ASCII string. The - first day of the month is - 01 - . -

Hour

- The hour of the day as a two digit ASCII string where midnight is - 00 - and 11:00pm is - 23 - . -

Minute

- The minute of the hour as a two digit ASCII string where the first - minute of the hour is - 00 - and the last is - 59 - . -

Second

- The second of the minute as a two digit ASCII string where the - first second of the minute is - 00 - and the last is - 59 - . -

Reserved

This field is reserved and should always be zero.

-
- -
-

- IV.A.2.p. The Shared Message Table - Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Shared Message Table
Header Message Type: 0x000F
Length: Fixed
Status: Optional; may not be repeated.
Description:This message is used to locate the table of shared object - header message (SOHM) indexes. Each index consists of information to - find the shared messages from either the heap or object header. This - message is only found in the superblock extension. -
Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - - - - - - - -
Shared Message Table Message
bytebytebytebyte
VersionThis space inserted - only to align table nicely

Shared Object Header Message Table - AddressO
-
Number of IndicesThis space inserted - only to align table nicely
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

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

Shared Object Header Message Table Address

This field is the address of the master table for - shared object header message indexes.

Number of Indices

This field is the number of indices in the master - table.

-
- -
-

- IV.A.2.q. The Object Header - Continuation Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Object Header - Continuation
Header Message Type: 0x0010
Length: Fixed
Status: Optional; may be repeated.
Description:The object header continuation is the location in the file - of a block containing more header messages for the current data - object. This can be used when header blocks become too large or are - likely to change over time.
Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - -
Object Header Continuation Message
bytebytebytebyte

OffsetO
-

LengthL
-
- - - - - - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
 (Items marked with an ‘L’ in the above table are - of the size specified in “Size of Lengths” field in the - superblock.)
- -
- -
-
- - - - - - - - - - - - - - - -
Field NameDescription

Offset

This value is the address in the file where the - header continuation block is located.

Length

This value is the length in bytes of the header - continuation block in the file.

-
-
- -

The format of the header continuation block that this message - points to depends on the version of the object header that the message - is contained within.

- -

- Continuation blocks for version 1 object headers have no special - formatting information; they are merely a list of object header message - info sequences (type, size, flags, reserved bytes and data for each - message sequence). See the description of Version 1 Data Object Header Prefix. -

- -

- Continuation blocks for version 2 object headers do have - special formatting information as described here (see also the - description of Version 2 Data - Object Header Prefix.): -

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Version 2 Object Header Continuation Block
bytebytebytebyte
Signature
Header Message Type #1Size of Header Message Data #1Header Message #1 Flags
Header Message #1 Creation Order (optional)This space inserted - only to align table nicely

Header Message Data #1
-
.
.
.
Header Message Type #nSize of Header Message Data #nHeader Message #n Flags
Header Message #n Creation Order (optional)This space inserted - only to align table nicely

Header Message Data #n
-
Gap (optional, variable size)
Checksum
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Signature

 -

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

-

Header Message #n Type

 -

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

-

Size of Header Message #n Data

 -

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

-

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.

-
-
- -
-

- IV.A.2.r. The Symbol Table Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Symbol Table Message
Header Message Type: 0x0011
Length: Fixed
Status: Required for “old - style” groups; may not be repeated.
Description:Each “old style” group has a v1 B-tree and a - local heap for storing symbol table entries, which are located with - this message.
Format of data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - -
- Symbol Table Message -
bytebytebytebyte

v1 B-tree AddressO
-

Local Heap AddressO
-
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - -
Field NameDescription

v1 B-tree Address

This value is the address of the v1 B-tree containing - the symbol table entries for the group.

Local Heap Address

This value is the address of the local heap - containing the link names for the symbol table entries for the - group.

-
- -
-

- IV.A.2.s. The Object Modification - Time Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Object Modification - Time
Header Message Type: 0x0012
Length: Fixed
Status: Optional; may not be repeated.
Description:The object modification time is a timestamp which indicates - the time of the last modification of an object. The time is updated - when any object header message changes according to the system clock - where the change was posted.
Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - -
Modification Time Message
bytebytebytebyte
VersionReserved (zero)
Seconds After UNIX Epoch
-
- -
-
- - - - - - - - - - - - - - - -
Field NameDescription

Version

The version number is used for changes in the format - of Object Modification Time and is described here:

- - - - - - - - - - - - - - - -
VersionDescription
0Never used.
1Used by Version 1.6.1 and after of the library to encode - time. In this version, the time is the seconds after Epoch.
-

Seconds After UNIX Epoch

A 32-bit unsigned integer value that stores the - number of seconds since 0 hours, 0 minutes, 0 seconds, January 1, - 1970, Coordinated Universal Time.

-
- -
-

- IV.A.2.t. The B-tree ‘K’ - Values Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: B-tree - ‘K’ Values
Header Message Type: 0x0013
Length: Fixed
Status: Optional; may not be repeated.
Description:This message retrieves non-default ‘K’ values - for internal and leaf nodes of a group or indexed storage v1 - B-trees. This message is only found in the superblock - extension. -
Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - - - -
B-tree ‘K’ Values Message
bytebytebytebyte
VersionIndexed Storage Internal Node KThis space inserted only to align - table nicely
Group Internal Node KGroup Leaf Node K
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

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

Indexed Storage Internal Node K

This is the node ‘K’ value for each - internal node of an indexed storage v1 B-tree. See the description - of this field in version 0 and 1 of the superblock as well the - section on v1 B-trees.

Group Internal Node K

This is the node ‘K’ value for each - internal node of a group v1 B-tree. See the description of this - field in version 0 and 1 of the superblock as well as the section - on v1 B-trees.

Group Leaf Node K

This is the node ‘K’ value for each leaf - node of a group v1 B-tree. See the description of this field in - version 0 and 1 of the superblock as well as the section on v1 - B-trees.

-
- -
-

- IV.A.2.u. The Driver Info Message -

- - -
- - - - - - - - - - - - - - - - - - - - - -
Header Message Name: Driver Info
Header Message Type: 0x0014
Length: Varies
Status: Optional; may not be repeated.
Description:This message contains information needed by the file driver - to reopen a file. This message is only found in the - superblock extension: see the - “Disk Format: Level 0C - Superblock Extension” section - for more information. For more information on the fields in the - driver info message, see the “Disk - Format : Level 0B - File Driver Info” section; those who use - the multi and family file drivers will find this section - particularly helpful. -
Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Driver Info Message
bytebytebytebyte
VersionThis space inserted - only to align table nicely

Driver Identification
Driver Information SizeThis space inserted - only to align table nicely

-
Driver Information (variable size)
-
-
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

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

Driver Identification

This is an eight-byte ASCII string without null - termination which identifies the driver.

Driver Information Size

- The size in bytes of the Driver Information field of this - message. -

Driver Information

Driver information is stored in a format defined by - the file driver.

-
- -
-

- IV.A.2.v. The Attribute Info Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Attribute Info
Header Message Type: 0x0015
Length: Varies
Status: Optional; may not be repeated.
Description:This message stores information about the attributes on an - object, such as the maximum creation index for the attributes - created and the location of the attribute storage when the - attributes are stored “densely”.
Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - -
Attribute Info Message
bytebytebytebyte
VersionFlagsMaximum Creation Index (optional)

Fractal Heap AddressO
-

Attribute Name v2 B-tree AddressO
-

Attribute Creation Order v2 B-tree - AddressO (optional)
-
- - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

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

Flags

This is the attribute index information flag with the - following definition:

- - - - - - - - - - - - - - - - - - -
BitDescription
0If set, creation order for attributes is tracked.
1If set, creation order for attributes is indexed.
2-7Reserved
-

Maximum Creation Index

The is the maximum creation order index value for the - attributes on the object.

-

- 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 attributes.

Attribute Name v2 B-tree Address

This is the address of the version 2 B-tree to index - the names of densely stored attributes.

Attribute Creation Order v2 B-tree Address

This is the address of the version 2 B-tree to index - the creation order of densely stored attributes.

-

- This field is present if bit 1 of Flags is set. -

-
- -
-

- IV.A.2.w. The Object Reference Count - Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: Object Reference - Count
Header Message Type: 0x0016
Length: Fixed
Status: Optional; may not be repeated.
Description:This message stores the number of hard links (in groups or - objects) pointing to an object: in other words, its reference - count. -
Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - -
Object Reference Count
bytebytebytebyte
VersionThis space inserted - only to align table nicely
Reference count
-
- -
-
- - - - - - - - - - - - - - - - -
Field NameDescription

Version

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

Reference Count

The unsigned 32-bit integer is the reference count - for the object. This message is only present in “version - 2” (or later) object headers, and if not present those object - header versions, the reference count for the object is assumed to - be 1.

-
- -
-

- IV.A.2.x. The File Space Info Message -

- - -
- - - - - - - - - - - - - - - - - - - - -
Header Message Name: File Space Info
Header Message Type: 0x0018
Length: Fixed
Status: Optional; may not be repeated.
Description:This message stores the file space management strategy (see - description below) that the library uses in handling file space - request for the file. It also contains the free-space section - threshold used by the library’s free-space managers for the - file. If the strategy is 1, this message also contains the addresses - of the file’s free-space managers which track free space for - each type of file space allocation. There are six basic types of - file space allocation: superblock, B-tree, raw data, global heap, - local heap, and object header. See the description of Free-space Manager as well the - description of allocation types in Appendix - B. -
Format of Data: See the tables below.
-
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
File Space Info
bytebytebytebyte
VersionStrategyThresholdL
Super-block Free-space Manager AddressO
B-tree Free-space Manager AddressO
Raw Data Free-space Manager AddressO
Global Heap Free-space Manager AddressO
Local Heap Free-space Manager AddressO
Object Header Free-space Manager AddressO
- - - - - - - - - - -
 (Items marked with an ‘O’ in the - above table are of the size specified in “Size of - Offsets” field in the superblock.)
 (Items marked with an ‘L’ in the above table are - of the size specified in “Size of Lengths” field in the - superblock.)
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field NameDescription

Version

This is the version number of this message. This - document describes version 0.

Strategy

This is the file space management strategy for the - file. There are four types of strategies:

- - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
1With this strategy, the HDF5 Library’s free-space - managers track the free space that results from the manipulation - of HDF5 objects in the HDF5 file. The free space information is - saved when the file is closed, and reloaded when the file is - reopened.
When space is needed for file metadata or raw - data, the HDF5 Library first requests space from the - library’s free-space managers. If the request is not - satisfied, the library requests space from the aggregators. If - the request is still not satisfied, the library requests space - from the virtual file driver. That is, the library will use all - of the mechanisms for allocating space. -
2This is the HDF5 Library’s default file space - management strategy. With this strategy, the library’s - free-space managers track the free space that results from the - manipulation of HDF5 objects in the HDF5 file. The free space - information is NOT saved when the file is closed and the free - space that exists upon file closing becomes unaccounted space in - the file.
As with strategy #1, the library will try all - of the mechanisms for allocating space. When space is needed for - file metadata or raw data, the library first requests space from - the free-space managers. If the request is not satisfied, the - library requests space from the aggregators. If the request is - still not satisfied, the library requests space from the virtual - file driver. -
3With this strategy, the HDF5 Library does not track free - space that results from the manipulation of HDF5 objects in the - HDF5 file and the free space becomes unaccounted space in the - file.
When space is needed for file metadata or raw data, - the library first requests space from the aggregators. If the - request is not satisfied, the library requests space from the - virtual file driver. -
4With this strategy, the HDF5 Library does not track free - space that results from the manipulation of HDF5 objects in the - HDF5 file and the free space becomes unaccounted space in the - file.
When space is needed for file metadata or raw data, - the library requests space from the virtual file driver. -
-

Threshold

- This is the free-space section threshold. The library’s - free-space managers will track only free-space sections with size - greater than or equal to threshold. The default is to - track free-space sections of all sizes. -

Superblock Free-space Manager Address

This is the address of the free-space manager for - H5FD_MEM_SUPER allocation type.

B-tree Free-space Manager Address

This is the address of the free-space manager for - H5FD_MEM_BTREE allocation type.

Raw Data Free-space Manager Address

This is the address of the free-space manager for - H5FD_MEM_DRAW allocation type.

Global Heap Free-space Manager Address

This is the address of the free-space manager for - H5FD_MEM_GHEAP allocation type.

Local Heap Free-space Manager Address

This is the address of the free-space manager for - H5FD_MEM_LHEAP allocation type.

Object Header Free-space Manager Address

This is the address of the free-space manager for - H5FD_MEM_OHDR allocation type.

-
-
- - -
-

- IV.B. Disk Format: Level 2B - Data Object - Data Storage -

- -

The data for an object is stored separately from its header - information in the file and may not actually be located in the HDF5 - file itself if the header indicates that the data is stored externally. - The information for each record in the object is stored according to - the dimensionality of the object (indicated in the dataspace header - message). Multi-dimensional array data is stored in C order; in other - words, the “last” dimension changes fastest.

- -

Data whose elements are composed of atomic datatypes are stored - in IEEE format, unless they are specifically defined as being stored in - a different machine format with the architecture-type information from - the datatype header message. This means that each architecture will - need to [potentially] byte-swap data values into the internal - representation for that particular machine.

- -

Data with a variable-length datatype is stored in the global heap - of the HDF5 file. Global heap identifiers are stored in the data object - storage.

- -

Data whose elements are composed of reference datatypes are - stored in several different ways depending on the particular reference - type involved. Object pointers are just stored as the offset of the - object header being pointed to with the size of the pointer being the - same number of bytes as offsets in the file.

- -

Dataset region references are stored as a heap-ID which points to - the following information within the file-heap: an offset of the object - pointed to, number-type information (same format as header message), - dimensionality information (same format as header message), sub-set - start and end information (in other words, a coordinate location for - each), and field start and end names (in other words, a [pointer to - the] string indicating the first field included and a [pointer to the] - string name for the last field).

- -

Data of a compound datatype is stored as a contiguous stream of - the items in the structure, with each item formatted according to its - datatype.

- - - -
-
-
-

- V. Appendix A: Definitions -

- -

Definitions of various terms used in this document are included - in this section.

- -
- - - - - - - - - - - - - - - - -
TermDefinition
Undefined AddressThe undefined address for a - file is a file address with all bits set: in other words, 0xffff...ff. -
Unlimited SizeThe unlimited size for a size is - a value with all bits set: in other words, 0xffff...ff. -
-
- - - -
-
-
-

- VI. Appendix B: File Memory Allocation Types -

- -

There are six basic types of file memory allocation as follows:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Basic Allocation TypeDescription
H5FD_MEM_SUPERFile memory allocated for Superblock.
H5FD_MEM_BTREEFile memory allocated for B-tree.
H5FD_MEM_DRAWFile memory allocated for raw data.
H5FD_MEM_GHEAPFile memory allocated for Global Heap.
H5FD_MEM_LHEAPFile memory allocated for Local Heap.
H5FD_MEM_OHDRFile memory allocated for Object Header.
-
- -

There are other file memory allocation types that are mapped to - the above six basic allocation types because they are similar in - nature. The mapping is listed in the following table:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Basic Allocation TypeMapping of Allocation Types to Basic Allocation Types
H5FD_MEM_SUPERnone
H5FD_MEM_BTREEH5FD_MEM_SOHM_INDEX
H5FD_MEM_DRAWH5FD_MEM_FHEAP_HUGE_OBJ
H5FD_MEM_GHEAPnone
H5FD_MEM_LHEAPH5FD_MEM_FHEAP_DBLOCK, H5FD_MEM_FSPACE_SINFO
H5FD_MEM_OHDRH5FD_MEM_FHEAP_HDR, H5FD_MEM_FHEAP_IBLOCK, - H5FD_MEM_FSPACE_HDR, H5FD_MEM_SOHM_TABLE
-
- -

Allocation types that are mapped to basic allocation types are - described below:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Allocation TypeDescription
H5FD_MEM_FHEAP_HDRFile memory allocated for Fractal Heap Header.
H5FD_MEM_FHEAP_DBLOCKFile memory allocated for Fractal Heap Direct - Blocks.
H5FD_MEM_FHEAP_IBLOCKFile memory allocated for Fractal Heap Indirect - Blocks.
H5FD_MEM_FHEAP_HUGE_OBJFile memory allocated for huge objects in the fractal heap.
H5FD_MEM_FSPACE_HDRFile memory allocated for Free-space Manager - Header.
H5FD_MEM_FSPACE_SINFOFile memory allocated for Free-space Section List - of the free-space manager. -
H5FD_MEM_SOHM_TABLEFile memory allocated for Shared Object Header - Message Table.
H5FD_MEM_SOHM_INDEXFile memory allocated for Shared Message Record - List.
-
-
- - diff --git a/doxygen/examples/H5.format.html b/doxygen/examples/H5.format.html deleted file mode 100644 index 2272a2b5eff..00000000000 --- a/doxygen/examples/H5.format.html +++ /dev/null @@ -1,20546 +0,0 @@ - - - - HDF5 File Format Specification Version 3.0 - - - - - - - - - - -
-
- - - - - - - -
-
    -
  1. Introduction
    2. - -
      -
    1. This Document
      2. -
    2. Changes for HDF5 1.12
      3. -
    3. Changes for HDF5 1.10
      4. -
    -     - -
  2. Disk Format: Level 0 - File Metadata
    3. - -
      -
    1. Disk Format: Level 0A - Format Signature - and Superblock
      2. -
    2. Disk Format: Level 0B - File Driver - Info
      3. -
    3. Disk Format: Level 0C - Superblock - Extension
      4. -
    -     -
  3. Disk Format: Level 1 - File Infrastructure
    4. - -
      -
    1. Disk Format: Level 1A - B-trees and B-tree - Nodes -
        -
      1. Disk Format: Level 1A1 - Version 1 - B-trees
        2. -
      2. Disk Format: Level 1A2 - Version 2 - B-trees
        3. -
      -
      2. -
    2. Disk Format: Level 1B - Group Symbol - Table Nodes
      3. -
    3. Disk Format: Level 1C - Symbol - Table Entry
      4. -
    4. Disk Format: Level 1D - Local Heaps
      5. -
    5. Disk Format: Level 1E - Global Heap
      6. -
    6. Disk Format: Level 1F - Global Heap - Block for Virtual Datasets
      7. -
    7. Disk Format: Level 1G - Fractal Heap
      8. -
    8. Disk Format: Level 1H - Free-space - Manager
      9. -
    9. Disk Format: Level 1I - Shared Object - Header Message Table
      10. -
    -     -
  4. Disk Format: Level 2 - Data Objects
    5. - -
      -
    1. Disk Format: Level 2A - Data Object Headers
      2. -
        -
      1. Disk Format: Level 2A1 - - Data Object Header Prefix -
          -
        1. Version 1 Data - Object Header Prefix
          2. -
        2. Version 2 Data - Object Header Prefix
          3. -
        -
        2. -
      2. Disk Format: Level 2A2 - - Data Object Header Messages
        3. -
          -
        1. The NIL Message
          2. -
        2. The Dataspace Message
          3. -
        3. The Link Info Message
          4. -
        4. The Datatype Message
          5. -
        5. The Data Storage - - Fill Value (Old) Message
          6. -
        -
      -
    -     -
- 		  -
    -
  1. Disk Format: Level 2 - Data - Objects (Continued)
    2. -
      -
    1. Disk Format: Level 2A - Data Object - Headers (Continued) -
        -
      1. Disk Format: Level 2A2 - - Data Object Header Messages (Continued)
        2. -
          -
        1. The Data Storage - - Fill Value Message
          2. -
        2. The Link Message
          3. -
        3. The Data Storage - - External Data Files Message
          4. -
        4. The Data Layout Message
          5. -
        5. The Bogus Message
          6. -
        6. The Group Info - Message
          7. -
        7. The Data Storage - - Filter Pipeline Message
          8. -
        8. The Attribute - Message
          9. -
        9. The Object Comment - Message
          10. -
        10. The Object - Modification Time (Old) Message
          11. -
        11. The Shared Message - Table Message
          12. -
        12. The Object Header - Continuation Message
          13. -
        13. The Symbol - Table Message
          14. -
        14. The Object - Modification Time Message
          15. -
        15. The B-tree - ‘K’ Values Message
          16. -
        16. The Driver Info - Message
          17. -
        17. The Attribute Info - Message
          18. -
        18. The Object Reference - Count Message
          19. -
        19. The File Space Info - Message
          20. -
        -
      -
      2. -
    2. Disk Format: Level 2B - Data Object Data Storage
      3. -
    -     -
  2. Appendix A: Definitions
    3. -
  3. Appendix B: File Space Allocation - Types
    4. -
  4. - Appendix C: Types of Indexes for Dataset Chunks
    5. - -
      -
    1. The Single Chunk Index
      2. -
    2. The Implicit Index
      3. -
    3. The Fixed Array Index
      4. -
    4. The Extensible Array Index
      5. -
    5. The Version 2 B-trees Index
      6. -
    -     -
  5. - Appendix D: Encoding for Dataspace and Reference
    6. - -
      -
    1. Dataspace Encoding
      2. -
    2. Reference Encoding (Revised)
      3. -
    3. Reference Encoding (Backward Compatibility)
      4. -
    -     -
-
-
- - -

I. Introduction

 - - - - - - - -
  -
- HDF5 Groups - 		 
  - Figure 1: Relationships among the HDF5 root group, other groups, and objects -
- 		 
  - HDF5 Objects -  
  - Figure 2: HDF5 objects -- datasets, datatypes, or dataspaces -
- 		 
- - -

The format of an HDF5 file on disk encompasses several - key ideas of the HDF4 and AIO file formats as well as - addressing some shortcomings therein. The new format is - more self-describing than the HDF4 format and is more - uniformly applied to data objects in the file.

- -

An HDF5 file appears to the user as a directed graph. - The nodes of this graph are the higher-level HDF5 objects - that are exposed by the HDF5 APIs:

- - - -

At the lowest level, as information is actually written to the disk, - an HDF5 file is made up of the following objects:

- - -

The HDF5 Library uses these low-level objects to represent the - higher-level objects that are then presented to the user or - to applications through the APIs. For instance, a group is an - object header that contains a message that points to a local - heap (for storing the links to objects in the group) and to a - B-tree (which indexes the links). A dataset is an object header - that contains messages that describe the datatype, dataspace, - layout, filters, external files, fill value, and other elements - with the layout message pointing to either a raw data chunk or - to a B-tree that points to raw data chunks.

- - -

I.A. This Document

 - -

This document describes the lower-level data objects; - the higher-level objects and their properties are described - in the HDF5 User Guide.

- -

Three levels of information comprise the file format. - Level 0 contains basic information for identifying and - defining information about the file. Level 1 information contains - the information about the pieces of a file shared by many objects - in the file (such as B-trees and heaps). Level 2 is the rest - of the file and contains all of the data objects with each object - partitioned into header information, also known as - metadata, and data.

- -

The various components of the lower-level data objects are - described in pairs of tables. The first table shows the format - layout, and the second table describes the fields. The titles - of format layout tables begin with “Layout”. The - titles of the tables where the fields are described begin with - “Fields”. For example, the table that describes the - format of the version 2 B-tree header has - a title of “Layout: Version 2 B-tree Header”, and the - fields in the version 2 B-tree header are described in the table - titled “Fields: Version 2 B-tree Header”. - -

The sizes of various fields in the following layout tables are - determined by looking at the number of columns the field spans - in the table. There are exceptions:

- - -

Values for all fields in this document should be treated as unsigned - integers, unless otherwise noted in the description of a field. - Additionally, all metadata fields are stored in little-endian byte - order. -

- -

All checksums used in the format are computed with the - Jenkins’ - lookup3 algorithm. -

- -

Whenever a bit flag or field is mentioned for an entry, bits are - numbered from the lowest bit position in the entry. -

- -

Various format tables in this document have cells with - “This space inserted only to align table nicely”. These - entries in the table are just to make the table presentation nicer - and do not represent any values or padding in the file. -

- - -

I.B. Changes for HDF5 2.0

 -

The following sections have been - changed or added for the 2.0 release:

- - - -

I.B. Changes for HDF5 1.12

 -

The following sections have been - changed or added for the 1.12 release:

- - - - -

I.C. Changes for HDF5 1.10

 - -

The following sections have been - changed or added for the 1.10 release:

- - - - -

- II. Disk Format: Level 0 - File Metadata

- - - -

- II.A. Disk Format: Level 0A - Format Signature and Superblock

- -

The superblock may begin at certain predefined offsets within - the HDF5 file, allowing a block of unspecified content for - users to place additional information at the beginning (and - end) of the HDF5 file without limiting the HDF5 Library’s - ability to manage the objects within the file itself. This - feature was designed to accommodate wrapping an HDF5 file in - another file format or adding descriptive information to an HDF5 - file without requiring the modification of the actual file’s - information. The superblock is located by searching for the - HDF5 format signature at byte offset 0, byte offset 512, and at - successive locations in the file, each a multiple of two of - the previous location; in other words, at these byte offsets: - 0, 512, 1024, 2048, and so on.

- -

The superblock is composed of the format signature, followed by a - superblock version number and information that is specific to each - version of the superblock. - -

Currently, there are four versions of the superblock format: -

- -

Versions 0 and 1 of the superblock are described below:

- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Superblock (Versions 0 and 1) -
bytebytebytebyte

Format Signature - (8 bytes)

Version # of SuperblockVersion # of File’s Free Space StorageVersion # of Root Group Symbol Table EntryReserved (zero)
Version Number of Shared Header Message FormatSize of OffsetsSize of LengthsReserved (zero)
Group Leaf Node KGroup Internal Node K
File Consistency Flags
Indexed Storage Internal Node K1Reserved - (zero)1

Base AddressO


Address of File Free space InfoO


End of File AddressO


Driver Information Block AddressO

Root Group Symbol Table Entry
- - - - - - - - -
  - (Items marked with a ‘1’ in the above table are - new in version 1 of the superblock.) -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Superblock (Versions 0 and 1) -
Field NameDescription

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:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Decimal:13772687013102610
Hexadecimal:894844460d0a1a0a
ASCII C Notation:\211HDF\r\n\032\n
-
-

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 accidentally 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. -

-
-
- -
-
-
-

Versions 2 and 3 of the superblock are described below:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Superblock (Versions 2 and 3) -
bytebytebytebyte

Format Signature - (8 bytes)

Version # of SuperblockSize of OffsetsSize of LengthsFile Consistency Flags

Base AddressO


Superblock Extension AddressO


End of File AddressO


Root Group Object Header AddressO

Superblock Checksum
- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Superblock (Versions 2 and 3) -
Field NameDescription

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. -

-
-
- -
- -

- II.B. Disk Format: Level 0B - File Driver Info

- -

The driver information block is an optional region of the - file which contains information needed by the file driver - to reopen a file. The format is described below:

- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Driver Information Block -
bytebytebytebyte
VersionReserved
Driver Information Size

Driver Identification - (8 bytes)



Driver Information - (variable size)


-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Driver Information Block -
Field NameDescription

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

Driver information is stored in a format defined by the - file driver (see description below).
-
- -
-

The two drivers encoded in the Driver Identification - field are as follows:

- -

The format of the Driver Information field for the - above two drivers are described below:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Multi Driver Information -
bytebytebytebyte
Member MappingMember MappingMember MappingMember Mapping
Member MappingMember MappingReservedReserved

Address of Member File 1


End of Address for Member File 1


Address of Member File 2


End of Address for Member File 2


... ...


Address of Member File N


End of Address for Member File N


Name of Member File 1 - (variable size)


Name of Member File 2 - (variable size)


... ...


Name of Member File N - (variable size)

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Multi Driver Information -
Field NameDescription

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 MappingDescription
1The superblock data.
2The B-tree data.
3The raw data.
4The global heap data.
5The local heap data.
6The 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. -

-
-
- -
-
-
-
- - - - - - - - - - - - - - -
- Layout: Family Driver Information -
bytebytebytebyte

Size of Member File

-
- -
-
- - - - - - - - - - - -
- Fields: Family Driver Information -
Field NameDescription

Size of Member File

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

-
- -

- II.C. Disk Format: Level 0C - Superblock Extension

- -

The superblock extension is used to store superblock metadata - which is either optional, or added after the version of the superblock - was defined. Superblock extensions may only exist when version 2 - or later of the superblock is used. A superblock extension is an object - header which may hold the following messages:

- - - - -

- III. Disk Format: Level 1 - File Infrastructure

- -

- III.A. Disk Format: Level 1A - B-trees and B-tree Nodes

- -

B-trees allow flexible storage for objects which tend to grow - in ways that cause the object to be stored discontiguously. B-trees - are described in various algorithms books including “Introduction to - Algorithms” by Thomas H. Cormen, Charles E. Leiserson, and Ronald - L. Rivest. B-trees are used in several places in the HDF5 file format, - when an index is needed for another data structure.

- -

The version 1 B-tree structure described below is the original - index structure. The version 1 B-trees are being phased out in - favor of the version 2 B-trees described below. Note that both - types of structures may be found in the same file depending on - the application settings when creating the file.

- -

- III.A.1. Disk Format: Level 1A1 - Version 1 B-trees

- -

Version 1 B-trees in HDF5 files are an implementation of the - B-link tree. The sibling nodes at a particular level in - the tree are stored in a doubly-linked list. See the - “Efficient Locking for Concurrent Operations on B-trees” - paper by Phillip Lehman and S. Bing Yao as published in the - ACM Transactions on Database Systems, Vol. 6, No. 4, - December 1981.

- -

The B-trees implemented by the file format contain one more - key than the number of children. In other words, each child - pointer out of a B-tree node has a left key and a right key. - The pointers out of internal nodes point to sub-trees while - the pointers out of leaf nodes point to symbol nodes and - raw data chunks. - Aside from that difference, internal nodes and leaf nodes - are identical.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: B-tree Nodes -
bytebytebytebyte
Signature
Node TypeNode LevelEntries Used

Address of Left SiblingO


Address of Right SiblingO

Key 1 (variable size)

Address of Child 1O

Key 2 (variable size)

Address of Child 2O

...
Key 2K (variable size)

Address of Child 2KO

Key 2K+1 - (variable size)
- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: B-tree Nodes -
Field NameDescription

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 TypeDescription
0This tree points to group nodes.
1This 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. -

-
-
- -

- Conceptually, each B-tree node looks like this:

-
- - - - - - - - - - - - - -
key[0] child[0] key[1] child[1] key[2] ... ... key[N-1] child[N-1] key[N]
-
-
- - where child[i] is a pointer to a sub-tree (at a level - above Level 0) or to data (at Level 0). - Each key[i] describes an item stored by the B-tree - (a chunk or an object of a group node). The range of values - represented by child[i] is indicated by key[i] - and key[i+1]. - - -

The following question must next be answered: - “Is the value described by key[i] contained in - child[i-1] or in child[i]?” - The answer depends on the type of tree. - In trees for groups (node type 0), the object described by - key[i] is the greatest object contained in - child[i-1] while in chunk trees (node type 1) the - chunk described by key[i] is the least chunk in - child[i].

- -

That means that key[0] for group trees is sometimes unused; - it points to offset zero in the heap, which is always the - empty string and compares as “less-than” any valid - object name.

- -

And key[N] for chunk trees is sometimes unused; - it contains a chunk offset which compares as “greater-than” - any other chunk offset and has a chunk byte size of zero - to indicate that it is not actually allocated.

- -

- III.A.2. Disk Format: Level 1A2 - Version 2 B-trees

- -

Version 2 (v2) B-trees are “traditional” B-trees - with one major difference. Instead of just using a simple pointer - (or address in the file) to a child of an internal node, the pointer - to the child node contains two additional pieces of information: - the number of records in the child node itself, and the total number - of records in the child node and all its descendants. Storing this - additional information allows fast array-like indexing to locate - the nth record in the B-tree.

- -

The entry into a version 2 B-tree is a header which contains global - information about the structure of the B-tree. The root node - address - field in the header points to the B-tree root node, which is either an - internal or leaf node, depending on the value in the header’s - depth field. An internal node consists of records plus - pointers to further leaf or internal nodes in the tree. A leaf node - consists of solely of records. The format of the records depends on - the B-tree type (stored in the header).

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 2 B-tree Header -
bytebytebytebyte
Signature
VersionTypeThis space inserted only to align table nicely
Node Size
Record SizeDepth
Split PercentMerge PercentThis space inserted only to align table nicely

Root Node AddressO

Number of Records in Root NodeThis space inserted only to align table nicely

Total Number of Records in B-treeL

Checksum
- - - - - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 2 B-tree Header -
Field NameDescription

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

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 2 B-tree Internal Node -
bytebytebytebyte
Signature
VersionTypeRecords 0, 1, 2...N-1 (variable size)

Child Node Pointer 0O


Number of Records N0 for Child - Node 0 (variable size)

Total Number of Records for Child Node 0 - (optional, variable size)

Child Node Pointer 1O


Number of Records N1 for - Child Node 1 (variable size)

Total Number of Records for Child Node 1 - (optional, variable size)
...

Child Node Pointer NO


Number of Records Nn for - Child Node N (variable size)

Total Number of Records for Child Node N - (optional, variable size)
Checksum
- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
-
- - -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 2 B-tree Internal Node -
Field NameDescription

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. -

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 2 B-tree Leaf Node -
bytebytebytebyte
Signature
VersionTypeRecord 0, 1, 2...N-1 (variable size)
Checksum
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 2 B-tree Leaf Node -
Field NameDescription

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. -

-
-
- -
-
-
-

The record layout for each stored (in other words, non-testing) - B-tree type is as follows:

- -
- - - - - - - - - - - - - - - - - - - -
- Layout: Version 2 B-tree, Type 1 Record Layout - Indirectly - Accessed, Non-filtered, ‘Huge’ Fractal Heap Objects -
bytebytebytebyte

Huge Object AddressO


Huge Object LengthL


Huge Object IDL

- - - - - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 2 B-tree, Type 1 Record Layout - Indirectly - Accessed, Non-filtered, ‘Huge’ Fractal Heap Objects -
Field NameDescription

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. -

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 2 B-tree, Type 2 Record Layout - Indirectly - Accessed, Filtered, ‘Huge’ Fractal Heap Objects -
bytebytebytebyte

Filtered Huge Object AddressO


Filtered Huge Object LengthL

Filter Mask

Filtered Huge Object Memory SizeL


Huge Object IDL

- - - - - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 2 B-tree, Type 2 Record Layout - Indirectly - Accessed, Filtered, ‘Huge’ Fractal Heap Objects -
Field NameDescription

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. -

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - -
- Layout: Version 2 B-tree, Type 3 Record Layout - Directly - Accessed, Non-filtered, ‘Huge’ Fractal Heap Objects -
bytebytebytebyte

Huge Object AddressO


Huge Object LengthL

- - - - - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - -
- Fields: Version 2 B-tree, Type 3 Record Layout - Directly - Accessed, Non-filtered, ‘Huge’ Fractal Heap Objects -
Field NameDescription

Huge Object Address

 -

The address of the huge object in the file. -

-

Huge Object Length

 -

The length of the huge object in the file. -

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 2 B-tree, Type 4 Record Layout - Directly - Accessed, Filtered, ‘Huge’ Fractal Heap Objects -
bytebytebytebyte

Filtered Huge Object AddressO


Filtered Huge Object LengthL

Filter Mask

Filtered Huge Object Memory SizeL

- - - - - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 2 B-tree, Type 4 Record Layout - Directly - Accessed, Filtered, ‘Huge’ Fractal Heap Objects -
Field NameDescription

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. -

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 2 B-tree, Type 5 Record Layout - Link Name - for Indexed Group -
bytebytebytebyte
Hash of Name
ID (bytes 1-4)
ID (bytes 5-7)
-
- -
-
- - - - - - - - - - - - - - - - - -
- Fields: Version 2 B-tree, Type 5 Record Layout - Link Name - for Indexed Group -
Field NameDescription

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.

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - -
- Layout: Version 2 B-tree, Type 6 Record Layout - Creation - Order for Indexed Group -
bytebytebytebyte

Creation Order - (8 bytes)

ID (bytes 1-4)
ID (bytes 5-7)
-
- -
-
- - - - - - - - - - - - - - - - - -
- Fields: Version 2 B-tree, Type 6 Record Layout - Creation - Order for Indexed Group -
Field NameDescription

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.

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 2 B-tree, Type 7 Record Layout - Shared - Object Header Messages (Sub-type 0 - Message in Heap) -
bytebytebytebyte
Message LocationThis space inserted only to align table nicely
Hash
Reference Count

Heap ID (8 bytes)

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 2 B-tree, Type 7 Record Layout - Shared - Object Header Messages (Sub-type 0 - Message in Heap) -
Field NameDescription

Message Location

 -

This field Indicates the location where the message is stored: - - - - - - - - - - - - - -
ValueDescription
0Shared message is stored in shared message index heap. -
1Shared 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.

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 2 B-tree, Type 7 Record Layout - Shared - Object Header Messages (Sub-type 1 - Message in Object Header) -
bytebytebytebyte
Message LocationThis space inserted only to align table nicely
Hash
Reserved (zero)Message TypeObject Header Index

Object Header AddressO

- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 2 B-tree, Type 7 Record Layout - Shared - Object Header Messages (Sub-type 1 - Message in Object Header) -
Field NameDescription

Message Location

 -

This field Indicates the location where the message is stored: - - - - - - - - - - - - - -
ValueDescription
0Shared message is stored in shared message index heap. -
1Shared 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 nth message - of its type in the specified object header.

-

Object Header Address

 -

The address of the object header containing the shared message.

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 2 B-tree, Type 8 Record Layout - Attribute - Name for Indexed Attributes -
bytebytebytebyte

Heap ID (8 bytes)

Message FlagsThis space inserted only to align table nicely
Creation Order
Hash of Name
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 2 B-tree, Type 8 Record Layout - Attribute - Name for Indexed Attributes -
Field NameDescription

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. -

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - -
- Layout: Version 2 B-tree, Type 9 Record Layout - Creation - Order for Indexed Attributes -
bytebytebytebyte

Heap ID (8 bytes)

Message Flags - This space inserted only to align table nicely
Creation Order
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 2 B-tree, Type 9 Record Layout - Creation - Order for Indexed Attributes -
Field NameDescription

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. -

-
-
- -
-
-
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - Layout: Version 2 B-tree, Type 10 Record Layout - - Non-filtered Dataset Chunks -
bytebytebytebyte

AddressO


Dimension 0 Scaled Offset - (8 bytes)


Dimension 1 Scaled Offset - (8 bytes)


...


Dimension #n Scaled Offset - (8 bytes)

- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - -
- Fields: Version 2 B-tree, Type 10 Record Layout - - Non-filtered Dataset Chunks -
Field NameDescription

Address

 -

This field is the address of the dataset chunk in the file.

-

Dimension #n Scaled Offset

 -

This field is the scaled offset of the chunk within the - dataset. n is the number of dimensions for the - dataset. The first scaled offset stored in the list is for - the slowest changing dimension, and the last scaled offset - stored is for the fastest changing dimension. Scaled offset - is calculated by dividing the chunk dimension sizes into - the chunk offsets.

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - Layout: Version 2 B-tree, Type 11 Record Layout - Filtered - Dataset Chunks -
bytebytebytebyte

AddressO


Chunk Size - (variable size; at most 8 bytes)

Filter Mask

Dimension 0 Scaled Offset - (8 bytes)


Dimension 1 Scaled Offset - (8 bytes)


...


Dimension #n Scaled Offset - (8 bytes)

- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 2 B-tree, Type 11 Record Layout - Filtered - Dataset Chunks -
Field NameDescription

Address

 -

This field is the address of the dataset chunk in the file.

-

Chunk Size

 -

This field is the size of the dataset chunk in bytes.

-

Filter Mask

 -

This field is the filter mask which indicates the filter - to skip for the dataset chunk. Each filter has an index - number in the pipeline and if that filter is skipped, - the bit corresponding to its index is set.

-

Dimension #n Scaled Offset

 -

This field is the scaled offset of the chunk within - the dataset. n is the number of dimensions for - the dataset. The first scaled offset stored in the list - is for the slowest changing dimension, and the last scaled - offset stored is for the fastest changing dimension.

-
-
- -

- III.B. Disk Format: Level 1B - Group Symbol Table Nodes

- -

A group is an object internal to the file that allows - arbitrary nesting of objects within the file (including other - groups). A group maps a set of link names in the group to a set - of relative file addresses of objects in the file. Certain metadata - for an object to which the group points can be cached in the - group’s symbol table entry in addition to being in the - object’s header.

- -

An HDF5 object name space can be stored hierarchically by - partitioning the name into components and storing each - component as a link in a group. The link for a - non-ultimate component points to the group containing - the next component. The link for the last - component points to the object being named.

- -

One implementation of a group is a collection of symbol table - nodes indexed by a B-tree. Each symbol table node contains entries - for one or more links. If an attempt is made to add a link to an - already full symbol table node containing 2K entries, then - the node is split and one node contains K symbols and the - other contains K+1 symbols.

- -
- - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Symbol Table Node (A Leaf of a B-tree) -
bytebytebytebyte
Signature
Version NumberReserved (zero)Number of Symbols


Group Entries


-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Symbol Table Node (A Leaf of a B-tree) -
Field NameDescription

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. -

-
-
- -

- III.C. Disk Format: Level 1C - Symbol Table Entry

- -

Each symbol table entry in a symbol table node is designed - to allow for very fast browsing of stored objects. - Toward that design goal, the symbol table entries - include space for caching certain constant metadata from the - object header.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Symbol Table Entry -
bytebytebytebyte

Link Name OffsetO


Object Header AddressO

Cache Type
Reserved (zero)


Scratch-pad Space - (16 bytes)


- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Symbol Table Entry -
Field NameDescription

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: - - - - - - - - - - - - - - - - - - -
TypeDescription
0No 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. -
1Group object header metadata is cached in the - scratch-pad space. This implies that the symbol table - entry refers to another group. -
2The 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. -

-
-
- -

Format of the Scratch-pad Space

- -

The symbol table entry scratch-pad space is formatted - according to the value in the Cache Type field.

- -

If the Cache Type field contains the value zero - (0) then no information is - stored in the scratch-pad space.

- -

If the Cache Type field contains the value one - (1), then the scratch-pad space - contains cached metadata for another object header - in the following format:

- -
- - - - - - - - - - - - - - - - - -
- Layout: Object Header Scratch-pad Format -
bytebytebytebyte

Address of B-treeO


Address of Name HeapO

- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - -
- Fields: Object Header Scratch-pad Format -
Field NameDescription

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. -

-
-
- - -
-
-
-

If the Cache Type field contains the value two - (2), then the scratch-pad space - contains cached metadata for a symbolic link - in the following format:

- -
- - - - - - - - - - - - - -
- Layout: Symbolic Link Scratch-pad Format -
bytebytebytebyte
Offset to Link Value
-
- -
-
- - - - - - - - - - - -
- Fields: Symbolic Link Scratch-pad Format -
Field NameDescription

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. -

-
-
- -

- III.D. Disk Format: Level 1D - Local Heaps

- -

A local heap is a collection of small pieces of data that are particular - to a single object in the HDF5 file. Objects can be - inserted and removed from the heap at any time. - The address of a heap does not change once the heap is created. - For example, a group stores addresses of objects in symbol table nodes - with the names of links stored in the group’s local heap. -

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Local Heap -
bytebytebytebyte
Signature
VersionReserved (zero)

Data Segment SizeL


Offset to Head of Free-listL


Address of Data SegmentO

- - - - - - - - -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Local Heap -
Field NameDescription

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. -

-
-
- -

Objects within a local heap should be aligned on an 8-byte boundary.

- -

- III.E. Disk Format: Level 1E - Global Heap

- -

Each HDF5 file has a global heap which stores various types of - information which is typically shared between datasets. The - global heap was designed to satisfy these goals:

- -
    -
  1. Repeated access to a heap object must be efficient without - resulting in repeated file I/O requests. Since global heap - objects will typically be shared among several datasets, it is - probable that the object will be accessed repeatedly.
    2. -
  2. Collections of related global heap objects should result in - fewer and larger I/O requests. For instance, a dataset of - object references will have a global heap object for each - reference. Reading the entire set of object references - should result in a few large I/O requests instead of one small - I/O request for each reference.
    3. -
  3. It should be possible to remove objects from the global heap - and the resulting file hole should be eligible to be reclaimed - for other uses.
    4. -
- - -

The implementation of the heap makes use of the memory management - already available at the file level and combines that with a new - object called a collection to achieve goal B. The global heap - is the set of all collections. Each global heap object belongs to - exactly one collection, and each collection contains one or more global - heap objects. For the purposes of disk I/O and caching, a collection is - treated as an atomic object, addressing goal A. -

- -

When a global heap object is deleted from a collection (which - occurs when its reference count falls to zero), objects located - after the deleted object in the collection are packed down toward - the beginning of the collection, and the collection’s - global heap object 0 is created (if possible), or its size is - increased to account for the recently freed space. There are - no gaps between objects in each collection, with the possible - exception of the final space in the collection, if it is not - large enough to hold the header for the collection’s - global heap object 0. These features address goal C. -

- -

The HDF5 Library creates global heap collections as needed, so there may - be multiple collections throughout the file. The set of all of them is - abstractly called the “global heap”, although they do not actually link - to each other, and there is no global place in the file where you can - discover all of the collections. The collections are found simply by - finding a reference to one through another object in the file. For - example, data of variable-length datatype elements is stored in the - global heap and is accessed via a global heap ID. The format for - global heap IDs is described at the end of this section. -

- -

For more information on global heaps for virtual datasets, see - “Disk Format: Level 1F - Global Heap - Block for Virtual Datasets.”

-
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: A Global Heap Collection -
bytebytebytebyte
Signature
VersionReserved (zero)

Collection SizeL


Global Heap Object 1


Global Heap Object 2


...


Global Heap Object N


Global Heap Object 0 (free space)

- - - - - -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: A Global Heap Collection -
Field NameDescription

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. -

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Global Heap Object -
bytebytebytebyte
Heap Object IndexReference Count
Reserved (zero)

Object SizeL


Object Data

- - - - - -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Global Heap Object -
Field NameDescription

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. -

-
- -
- -
-
-
-

- - The format for the ID used to locate an object in the global heap is - described here:

- -
- - - - - - - - - - - - - - - - - -
- Layout: Global Heap ID -
bytebytebytebyte

Collection AddressO

Object Index
- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - -
- Fields: Global Heap ID -
Field NameDescription

Collection Address

 -

This field is the address of the global heap collection - where the data object is stored. -

-

ID

 -

This field is the index of the data object within the - global heap collection. -

-
-
- - - -

III.F. Disk Format: Level 1F - Global - Heap Block for Virtual Datasets

- -

The layout for the global heap block used with virtual datasets is - described below. For more information on global heaps, see - “Disk Format: Level 1E - Global Heap.”

- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Global Heap Block for Virtual Dataset -
bytebytebytebyte
VersionThis space inserted - only to align table nicely

Num EntriesL


Source Filename #1 (variable size)


Source Dataset #1 (variable - size)


Source Selection #1 (variable - size)


Virtual Selection #1 (variable - size)

.
.
.

Source Filename #n (variable - size)


Source Dataset #n (variable - size)


Source Selection #n (variable - size)


Virtual Selection #n (variable - size)

Checksum
- - - - - -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Global Heap Block for Virtual Dataset -
Field NameDescription

Version

 -

The version number for the block; the value is 0.

-

Num Entries

The number of entries in the block.

-

Source Filename #n

 -

The source file name where the source dataset is located. -

-

Source Dataset #n

The source dataset name that is mapped to the - virtual dataset.

Source Selection #n

 -

The dataspace selection in the - source dataset that is mapped to the virtual selection. -

-

Virtual Selection #n

 -

This is the dataspace selection in the virtual dataset that is - mapped to the source selection. -

-

Checksum

 -

This is the checksum for the block.

-
-
-
- -

- III.G. Disk Format: Level 1G - Fractal Heap

- -

- Each fractal heap consists of a header and zero or more direct and - indirect blocks (described below). The header contains general - information as well as - initialization parameters for the doubling table. The Address - of Root Block field in the header points to the first direct or - indirect block in the heap. -

- -

- Fractal heaps are based on a data structure called a doubling - table. A doubling table provides a mechanism for quickly - extending an array-like data structure that minimizes the number of - empty blocks in the heap, while retaining very fast lookup of any - element within the array. More information on fractal heaps and - doubling tables can be found in the RFC - “Private - Heaps in HDF5.” -

- -

- The fractal heap implements the doubling table structure with - indirect and direct blocks. - Indirect blocks in the heap do not actually contain data for - objects in the heap, their “size” is abstract - - they represent the indexing structure for locating the - direct blocks in the doubling table. - Direct blocks - contain the actual data for objects stored in the heap. -

- -

- All indirect blocks have a constant number of block entries in each - row, called the width of the doubling table - (see Table Width field in the header). - - The number - of rows for each indirect block in the heap is determined by the - size of the block that the indirect block represents in the - doubling table (calculation of this is shown below) and is - constant, except for the “root” - indirect block, which expands and shrinks its number of rows as - needed. -

- -

- Blocks in the first two rows of an indirect block - are Starting Block Size number of bytes in size. - For example, if the row width of the doubling table is 4, - then the first eight block entries in the - indirect block are Starting Block Size number of bytes in size. - The blocks in each subsequent row are twice the size of - the blocks in the previous row. In other words, blocks in - the third row are twice the Starting Block Size, - blocks in the fourth row are four times the - Starting Block Size, and so on. Entries for - blocks up to the Maximum Direct Block Size point to - direct blocks, and entries for blocks greater than that size - point to further indirect blocks (which have their own - entries for direct and indirect blocks). - Starting Block Size and - Maximum Direct Block Size are fields - stored in the header. -

- -

- The number of rows of blocks, nrows, in an - indirect block is calculated by the following expression: -

- nrows = (log2(block_size) - - log2(<Starting Block Size>)) + 1 -

-where block_size is the size of the block that the indirect block -represents in the doubling table. -For example, to represent a block with block_size equals to 1024, -and Starting Block Size equals to 256, -three rows are needed. -

- The maximum number of rows of direct blocks, max_dblock_rows, - in any indirect block of a fractal heap is given by the - following expression: -

- max_dblock_rows = - (log2(<Maximum Direct Block Size>) - - log2(<Starting Block Size>)) + 2 -

-

- Using the computed values for nrows and - max_dblock_rows, along with the width of the - doubling table, the number of direct and indirect block entries - (K and N in the indirect block description, below) - in an indirect block can be computed: -

- K = MIN(nrows, max_dblock_rows) * - <Table Width> - -

- If nrows is less than or equal to max_dblock_rows, - N is 0. Otherwise, N is simply computed: -

- N = K - (max_dblock_rows * - <Table Width>) -

- -

- The size of indirect blocks on disk is determined by the number - of rows in the indirect block (computed above). The size of direct - blocks on disk is exactly the size of the block in the doubling - table. -

-
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Fractal Heap Header -
bytebytebytebyte
Signature
VersionThis space inserted only to align table nicely
Heap ID LengthI/O Filters’ Encoded Length
FlagsThis space inserted only to align table nicely
Maximum Size of Managed Objects

Next Huge Object IDL


v2 B-tree Address of Huge ObjectsO


Amount of Free Space in Managed BlocksL


Address of Managed Block Free Space ManagerO


Amount of Managed Space in HeapL


Amount of Allocated Managed Space in HeapL


Offset of Direct Block Allocation Iterator in Managed SpaceL


Number of Managed Objects in HeapL


Size of Huge Objects in HeapL


Number of Huge Objects in HeapL


Size of Tiny Objects in HeapL


Number of Tiny Objects in HeapL

Table WidthThis space inserted only to align table nicely

Starting Block SizeL


Maximum Direct Block SizeL

Maximum Heap SizeStarting # of Rows in Root Indirect Block

Address of Root BlockO

Current # of Rows in Root Indirect BlockThis space inserted only to align table nicely

Size of Filtered Root Direct Block (optional)L

I/O Filter Mask (optional)
I/O Filter Information (optional, variable size)
Checksum
- - - - - - - - -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Fractal Heap Header -
Field NameDescription

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
0If 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. -
1If set, the direct blocks in the heap are checksummed. -
2-7Reserved

- -

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.

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Fractal Heap Direct Block -
bytebytebytebyte
Signature
VersionThis space inserted only to align table nicely

Heap Header AddressO

Block Offset (variable size)
Checksum (optional)

Object Data (variable size)

- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Fractal Heap Direct Block -
Field NameDescription

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). -

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Fractal Heap Indirect Block -
bytebytebytebyte
Signature
VersionThis space inserted only to align table nicely

Heap Header AddressO

Block Offset (variable size)

Child Direct Block #0 AddressO


Size of Filtered Direct Block #0 (optional) L

Filter Mask for Direct Block #0 (optional)

Child Direct Block #1 AddressO


Size of Filtered Direct Block #1 (optional)L

Filter Mask for Direct Block #1 (optional)
...

Child Direct Block #K-1 AddressO


Size of Filtered Direct Block #K-1 (optional)L

Filter Mask for Direct Block #K-1 (optional)

Child Indirect Block #0 AddressO


Child Indirect Block #1 AddressO

...

Child Indirect Block #N-1 AddressO

Checksum
- - - - - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Fractal Heap Indirect Block -
Field NameDescription

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.

-
- -
- -
-

An object in the fractal heap is identified by means of a fractal heap ID, - which encodes information to locate the object in the heap. - Currently, the fractal heap stores an object in one of three ways, - depending on the object’s size:

- -
- - - - - - - - - - - - - - - - - - - - -
TypeDescription
Tiny -

When an object is small enough to be encoded in the - heap ID, the object’s data is embedded in the fractal - heap ID itself. There are two sub-types for this type of - object: normal and extended. The sub-type for tiny heap - IDs depends on whether the heap ID is large enough to - store objects greater than 16 bytes or not. If the - heap ID length is 18 bytes or smaller, the - ‘normal’ tiny heap ID form is used. If the - heap ID length is greater than 18 bytes in length, the - “extended” form is used. See the format - description below for both sub-types. -

-
Huge -

When the size of an object is larger than Maximum Size of - Managed Objects in the Fractal Heap Header, the - object’s data is stored on its own in the file and the object - is tracked/indexed via a version 2 B-tree. All huge objects - for a particular fractal heap use the same v2 B-tree. All huge - objects for a particular fractal heap use the same format for - their huge object IDs. -

- -

Depending on whether the IDs for a heap are large enough to hold - the object’s retrieval information and whether I/O pipeline filters - are applied to the heap’s objects, 4 sub-types are derived for - huge object IDs for this heap:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - -
Sub-typeDescription
Directly accessed, non-filtered -

The object’s address and length are embedded in the - fractal heap ID itself and the object is directly accessed - from them. This allows the object to be accessed without - resorting to the B-tree. -

-
Directly accessed, filtered -

The filtered object’s address, length, filter mask and - de-filtered size are embedded in the fractal heap ID itself - and the object is accessed directly with them. This allows - the object to be accessed without resorting to the B-tree. -

-
Indirectly accessed, non-filtered -

The object is located by using a B-tree key embedded in - the fractal heap ID to retrieve the address and length from - the version 2 B-tree for huge objects. Then, the address - and length are used to access the object. -

-
Indirectly accessed, filtered -

The object is located by using a B-tree key embedded in - the fractal heap ID to retrieve the filtered object’s - address, length, filter mask and de-filtered size from the - version 2 B-tree for huge objects. Then, this information - is used to access the object. -

-
-
- -
Managed -

When the size of an object does not meet the above two - conditions, the object is stored and managed via the direct and - indirect blocks based on the doubling table. -

-
-
- - -
-

The specific format for each type of heap ID is described below: -

- -
- - - - - - - - - - - - - - - - - - - -
- Layout: Fractal Heap ID for Tiny Objects (Sub-type 1 - - ‘Normal’) -
bytebytebytebyte
Version, Type, and LengthThis space inserted only to align table nicely

Data (variable size)
-
- -
-
- - - - - - - - - - - - - - - - - -
- Fields: Fractal Heap ID for Tiny Objects (Sub-type 1 - - ‘Normal’) -
Field NameDescription

Version, Type, and Length

 -

This is a bit field with the following definition: - - - - - - - - - - - - - - - - - - -
BitDescription
6-7The current version of ID format. This document - describes version 0. -
4-5The ID type. Tiny objects have a value of 2. -
0-3The 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. -

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - -
- Layout: Fractal Heap ID for Tiny Objects (Sub-type 2 - - ‘Extended’) -
bytebytebytebyte
Version, Type, and LengthExtended LengthThis space inserted only to align table nicely
Data (variable size)
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - -
- Fields: Fractal Heap ID for Tiny Objects (Sub-type 2 - - ‘Extended’) -
Field NameDescription

Version, Type, and Length

 -

This is a bit field with the following definition: - - - - - - - - - - - - - - - - - - -
BitDescription
6-7The current version of ID format. This document - describes version 0. -
4-5The ID type. Tiny objects have a value of 2. -
0-3These 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. -

-
-
- - -
-
-
-
- - - - - - - - - - - - - - - - - - - -
- Layout: Fractal Heap ID for Huge Objects (Sub-types 1 and 2): - Indirectly Accessed, Non-filtered/Filtered -
bytebytebytebyte
Version and TypeThis space inserted - only to align table nicely

v2 B-tree KeyL (variable size)

- - - - - -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
-
- -
-
- - - - - - - - - - - - - - - - - -
- Fields: Fractal Heap ID for Huge Objects (Sub-types 1 and 2): - Indirectly Accessed, Non-filtered/Filtered -
Field NameDescription

Version and Type

 -

This is a bit field with the following definition: - - - - - - - - - - - - - - - - - - -
BitDescription
6-7The current version of ID format. This document - describes version 0. -
4-5The ID type. Huge objects have a value of 1. -
0-3Reserved. -

- -

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.

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Fractal Heap ID for Huge Objects (Sub-type 3): - Directly Accessed, Non-filtered -
bytebytebytebyte
Version and TypeThis space inserted only to align table nicely

Address O


Length L

- - - - - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - -
- Fields: Fractal Heap ID for Huge Objects (Sub-type 3): - Directly Accessed, Non-filtered -
Field NameDescription

Version and Type

 -

This is a bit field with the following definition: - - - - - - - - - - - - - - - - - - -
BitDescription
6-7The current version of ID format. This document - describes version 0. -
4-5The ID type. Huge objects have a value of 1. -
0-3Reserved. -

- -

Address

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

-

Length

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

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Fractal Heap ID for Huge Objects (Sub-type 4): - Directly Accessed, Filtered -
bytebytebytebyte
Version and TypeThis space inserted only to align table nicely

Address O


Length L

Filter Mask

De-filtered Size L

- - - - - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Fractal Heap ID for Huge Objects (Sub-type 4): - Directly Accessed, Filtered -
Field NameDescription

Version and Type

 -

This is a bit field with the following definition: - - - - - - - - - - - - - - - - - - -
BitDescription
6-7The current version of ID format. This document - describes version 0. -
4-5The ID type. Huge objects have a value of 1. -
0-3Reserved. -

- -

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.

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - -
- Layout: Fractal Heap ID for Managed Objects -
bytebytebytebyte
Version and TypeThis space inserted only to align table nicely
Offset (variable size)
Length (variable size)
-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
- Fields: Fractal Heap ID for Managed Objects -
Field NameDescription

Version and Type

This is a bit field with the following definition: - - - - - - - - - - - - - - - - - - -
BitDescription
6-7The current version of ID format. This document - describes version 0. -
4-5The ID type. Managed objects have a value of 0. -
0-3Reserved. -

-

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.

-
- -

- III.H. Disk Format: Level 1H - Free-space Manager

- -

- Free-space managers are used to describe space within a heap or - the entire HDF5 file that is not currently used for that heap or - file. -

- -

- The free-space manager header contains metadata information - about the space being tracked, along with the address of the list - of free space sections which actually describes the free - space. The header records information about free-space sections being - tracked, creation parameters for handling free-space sections of a - client, and section information used to locate the collection of - free-space sections. -

- -

- The free-space section list stores a collection of - free-space sections that is specific to each client of the - free-space manager. - - For example, the fractal heap is a client of the free space manager - and uses it to track unused space within the heap. There are 4 - types of section records for the fractal heap, each of which has - its own format, listed below. -

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Free-space Manager Header -
bytebytebytebyte
Signature
VersionClient IDThis space inserted only to align table nicely

Total Space TrackedL


Total Number of SectionsL


Number of Serialized SectionsL


Number of Un-Serialized SectionsL

Number of Section ClassesThis space inserted only to align table nicely
Shrink PercentExpand Percent
Size of Address SpaceThis space inserted only to align table nicely

Maximum Section Size L


Address of Serialized Section ListO


Size of Serialized Section List UsedL


Allocated Size of Serialized Section ListL

Checksum
- - - - - - - - -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Free-space Manager Header -
Field NameDescription

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: - - - - - - - - - - - - - - - - - - - -
IDDescription
0Fractal heap -
1File -
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 log2 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.

-
-
- -
-

The free-space sections being managed are stored in a - free-space section list, described below. The sections - in the free-space section list are stored in the following way: - a count of the number of sections describing a particular size of - free space and the size of the free-space described (in bytes), - followed by a list of section description records; then another - section count and size, followed by the list of section - descriptions for that size; and so on.

- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Free-space Section List -
bytebytebytebyte
Signature
VersionThis space inserted only to align table nicely

Free-space Manager Header AddressO

Number of Section Records in Set #0 (variable size)
Size of Free-space Section Described in Record Set #0 (variable size)
Record Set #0 Section Record #0 Offset(variable size)
Record Set #0 Section Record #0 TypeThis space inserted only to align table nicely
Record Set #0 Section Record #0 Data (variable size)
...
Record Set #0 Section Record #K-1 Offset(variable size)
Record Set #0 Section Record #K-1 TypeThis space inserted only to align table nicely
Record Set #0 Section Record #K-1 Data (variable size)
Number of Section Records in Set #1 (variable size)
Size of Free-space Section Described in Record Set #1 (variable size)
Record Set #1 Section Record #0 Offset(variable size)
Record Set #1 Section Record #0 TypeThis space inserted only to align table nicely
Record Set #1 Section Record #0 Data (variable size)
...
Record Set #1 Section Record #K-1 Offset(variable size)
Record Set #1 Section Record #K-1 TypeThis space inserted only to align table nicely
Record Set #1 Section Record #K-1 Data (variable size)
...
...
Number of Section Records in Set #N-1 (variable size)
Size of Free-space Section Described in Record Set #N-1 (variable size)
Record Set #N-1 Section Record #0 Offset(variable size)
Record Set #N-1 Section Record #0 TypeThis space inserted only to align table nicely
Record Set #N-1 Section Record #0 Data (variable size)
...
Record Set #N-1 Section Record #K-1 Offset(variable size)
Record Set #N-1 Section Record #K-1 TypeThis space inserted only to align table nicely
Record Set #N-1 Section Record #K-1 Data (variable size)
Checksum
- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Free-space Section List -
Field NameDescription

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: - - - - - - - - - - - - - - - -
TypeDescription
0File’s section (a range of actual bytes in file) -
1+Reserved. -

- -

The defined record types for a fractal heap client are: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TypeDescription
0Fractal heap “single” section -
1Fractal heap “first row” section -
2Fractal heap “normal row” section -
3Fractal 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. -

-
-
- -
-

- The section-type specific data for each free-space section record is - described below: -

- -
- - - - - - -
- Layout: File’s Section Data Record -
No additional record data stored
-
- -
-
-
-
- - - - - - -
- Layout: Fractal Heap “Single” Section Data Record -
No additional record data stored
-
- -
-
-
-
- - - - - - -
- Layout: Fractal Heap “First Row” Section Data - Record -
Same format as “indirect” - section data
-
- -
-
-
-
- - - - - - -
- Layout: Fractal Heap “Normal Row” Section Data - Record -
No additional record data stored
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Fractal Heap “Indirect” Section - Data Record -
bytebytebytebyte
Fractal Heap Indirect Block Offset (variable size)
Block Start RowBlock Start Column
Number of BlocksThis space inserted only to align table nicely
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Fractal Heap “Indirect” Section - Data Record -
Field NameDescription

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. -

-
-
- -

- III.I. Disk Format: Level 1I - Shared Object Header Message Table

- -

- The shared object header message table is used to locate - object - header messages that are shared between two or more object headers - in the file. Shared object header messages are stored and indexed - in the file in one of two ways: indexed sequentially in a - shared header message list or indexed with a v2 B-tree. - The shared messages themselves are either stored in a fractal - heap (when two or more objects share the message), or remain in an - object’s header (when only one object uses the message currently, - but the message can be shared in the future). -

- -

- The shared object header message table - contains a list of shared message index headers. Each index header - records information about the version of the index format, the index - storage type, flags for the message types indexed, the number of - messages in the index, the address where the index resides, - and the fractal heap address if shared messages are stored there. -

- -

- Each index can be either a list or a v2 B-tree and may transition - between those two forms as the number of messages in the index - varies. Each shared message record contains information used to - locate the shared message from either a fractal heap or an object - header. The types of messages that can be shared are: Dataspace, - Datatype, Fill Value, Filter Pipeline and Attribute. -

- -

- The shared object header message table is pointed to - from a shared message table message - in the superblock extension for a file. This message stores the - version of the table format, along with the number of index headers - in the table. -

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Shared Object Header Message Table -
bytebytebytebyte
Signature
Version for index #0Index Type for index #0Message Type Flags for index #0
Minimum Message Size for index #0
List Cutoff for index #0v2 B-tree Cutoff for index #0
Number of Messages for index #0This space inserted only to align table nicely

Index AddressO for index #0


Fractal Heap AddressO for index #0

...
...
Version for index #N-1Index Type for index #N-1Message Type Flags for index #N-1
Minimum Message Size for index #N-1
List Cutoff for index #N-1v2 B-tree Cutoff for index #N-1
Number of Messages for index #N-1This space inserted only to align table nicely

Index AddressO for index #N-1


Fractal Heap AddressO for index #N-1

Checksum
- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Shared Object Header Message Table -
Field NameDescription

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: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BitsDescription
0If set, the index tracks Dataspace Messages. -
1If set, the message tracks Datatype Messages. -
2If set, the message tracks Fill Value Messages. -
3If set, the message tracks Filter Pipeline Messages. -
4If set, the message tracks Attribute Messages. -
5-15Reserved (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.

-
-
- -
-

- Shared messages are indexed either with a shared message record - list, described below, or using a v2 B-tree (using record type 7). - The number of records in the shared message record list is - determined in the index’s entry in the shared object header message - table. -

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Shared Message Record List -
bytebytebytebyte
Signature
Shared Message Record #0
Shared Message Record #1
...
Shared Message Record #N-1
Checksum
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - -
- Fields: Shared Message Record List -
Field NameDescription

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. -

-
-
- -
-

- The record for each shared message in an index is stored in one - of the following forms: -

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Shared Message Record for Messages Stored in a - Fractal Heap -
bytebytebytebyte
Message LocationThis space inserted only to align table nicely
Hash Value
Reference Count

Fractal Heap ID

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Shared Message Record for Messages Stored in a - Fractal Heap -
Field NameDescription

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. -

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Shared Message Record for Messages Stored in an - Object Header -
bytebytebytebyte
Message LocationThis space inserted only to align table nicely
Hash Value
ReservedMessage TypeCreation Index

Object Header AddressO

- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Shared Message Record for Messages Stored in an - Object Header -
Field NameDescription

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. -

-
-
- -

- IV. Disk Format: Level 2 - Data Objects

- -

Data objects contain the “real” user-visible information in the file. - These objects compose the scientific data and other information which - are generally thought of as “data” by the end-user. All the - other information in the file is provided as a framework for - storing and accessing these data objects. -

- -

A data object is composed of header and data - information. The header information contains the information - needed to interpret the data information for the object as - well as additional “metadata” or pointers to additional - “metadata” used to describe or annotate each object. -

- -

- IV.A. Disk Format: Level 2A - Data Object Headers

- -

The header information of an object is designed to encompass - all of the information about an object, except for the data itself. - This information includes the dataspace, the datatype, information - about how the data is stored on disk (in external files, compressed, - broken up in blocks, and so on), as well as other information used - by the library to speed up access to the data objects or maintain - a file’s integrity. Information stored by user applications - as attributes is also stored in the object’s header. The header - of each object is not necessarily located immediately prior to the - object’s data in the file and in fact may be located in any - position in the file. The order of the messages in an object header - is not significant.

- -

Object headers are composed of a prefix and a set of messages. The - prefix contains the information needed to interpret the messages and - a small amount of metadata about the object, and the messages contain - the majority of the metadata about the object. -

- -

- IV.A.1. Disk Format: Level 2A1 - Data Object Header Prefix

- - - -

- IV.A.1.a. Version 1 Data Object Header Prefix

- -

Header messages are aligned on 8-byte boundaries for version 1 - object headers. -

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 1 Object Header -
bytebytebytebyte
VersionReserved (zero)Total Number of Header Messages
Object Reference Count
Object Header Size
Reserved (zero)
Header Message Type #1Size of Header Message Data #1
Header Message #1 FlagsReserved (zero)

Header Message Data #1

.
.
.
Header Message Type #nSize of Header Message Data #n
Header Message #n FlagsReserved (zero)

Header Message Data #n

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 1 Object Header -
Field NameDescription

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: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BitDescription
0If set, the message data is constant. This is used - for messages like the datatype message of a dataset. -
1If 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. -
2If set, the message should not be shared. -
3If 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) -
4If 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) -
5If 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) -
6If set, this message is shareable. -
7If 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. -

-
-
- -

- IV.A.1.b. Version 2 Data Object Header Prefix

- -

Note that the “total number of messages” field has been dropped from - the data object header prefix in this version. The number of messages - in the data object header is just determined by the messages encountered - in all the object header blocks.

- -

Note also that the fields and messages in this version of data object - headers have no alignment or padding bytes inserted - they are - stored packed together.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 2 Object Header -
bytebytebytebyte
Signature
VersionFlagsThis space inserted only to align table nicely
Access time (optional)
Modification Time (optional)
Change Time (optional)
Birth Time (optional)
Maximum # of compact attributes (optional)Minimum # of dense attributes (optional)
Size of Chunk #0 (variable size)This space inserted only to align table nicely
Header Message Type #1Size of Header Message Data #1Header Message #1 Flags
Header Message #1 Creation Order (optional)This space inserted only to align table nicely

Header Message Data #1

.
.
.
Header Message Type #nSize of Header Message Data #nHeader Message #n Flags
Header Message #n Creation Order (optional)This space inserted only to align table nicely

Header Message Data #n

Gap (optional, variable size)
Checksum
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 2 Object Header -
Field NameDescription

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-1This two bit field determines the size of the - Size of Chunk #0 field. The values are: - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0The Size of Chunk #0 field is 1 byte. -
1The Size of Chunk #0 field is 2 bytes. -
2The Size of Chunk #0 field is 4 bytes. -
3The Size of Chunk #0 field is 8 bytes. -
-
2If set, attribute creation order is tracked.
3If set, attribute creation order is indexed.
4If set, non-default attribute storage phase change - values are stored.
5If set, access, modification, change and birth times - are stored.
6-7Reserved

- -

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. -

-
-
- -

The header message types and the message data associated with - them compose the critical “metadata” about each object. Some - header messages are required for each object while others are - optional. Some optional header messages may also be repeated - several times in the header itself, the requirements and number - of times allowed in the header will be noted in each header - message description below. -

- - -

- IV.A.2. Disk Format: Level 2A2 - Data Object Header Messages

- -

Data object header messages are small pieces of metadata that are - stored in the data object header for each object in an HDF5 file. - Data object header messages provide the metadata required to describe - an object and its contents, as well as optional pieces of metadata - that annotate the meaning or purpose of the object. -

- -

Data object header messages are either stored directly in the data - object header for the object or are shared between multiple objects - in the file. When a message is shared, a flag in the Message Flags - indicates that the actual Message Data - portion of that message is stored in another location (such as another - data object header, or a heap in the file) and the Message Data - field contains the information needed to locate the actual information - for the message. -

- -

- The format of shared message data is described here:

- -
- - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Shared Message (Version 1) -
bytebytebytebyte
VersionTypeReserved (zero)
Reserved (zero)

AddressO

- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - -
- Fields: Shared Message (Version 1) -
Field NameDescription

Version

The version number is used when there are changes in the format - of a shared object message and is described here: - - - - - - - - - - - - - - - -
VersionDescription
0Never used.
1Used by the library before version 1.6.1. -

-

Type

The type of shared message location: - - - - - - - - - - -
ValueDescription
0Message stored in another object’s header (a committed - message). -

-

Address

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

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - -
- Layout: Shared Message (Version 2) -
bytebytebytebyte
VersionTypeThis space inserted only to align table nicely

AddressO

- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
- Fields: Shared Message (Version 2) -
Field NameDescription

Version

The version number is used when there are changes in the format - of a shared object message and is described here: - - - - - - - - - - -
VersionDescription
2Used by the library of version 1.6.1 and after. -

-

Type

The type of shared message location: - - - - - - - - - - -
ValueDescription
0Message stored in another object’s header (a committed - message). -

-

Address

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

-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - -
- Layout: Shared Message (Version 3) -
bytebytebytebyte
VersionTypeThis space inserted only to align table nicely
Location (variable size)
-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
- Fields: Shared Message (Version 3) -
Field NameDescription

Version

The version number indicates changes in the format of shared - object message and is described here: - - - - - - - - - - -
VersionDescription
3Used 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: - - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Message is not shared and is not shareable. -
1Message stored in file’s shared object header message - heap (a shared message). -
2Message stored in another object’s header (a committed - message). -
3Message stored is not shared, but is shareable. -

-

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. -

-
-
- - -

The following is a list of currently defined header messages: -

- -

IV.A.2.a. The NIL Message

- - -
- - - - - - - - -
Header Message Name: NIL
Header Message Type: 0x0000
Length: Varies
Status: Optional; may be repeated.
Description:The NIL message is used to indicate a message which is to be - ignored when reading the header messages for a data object. - [Possibly one which has been deleted for some reason.] -
Format of Data: Unspecified
- - - -

IV.A.2.b. The Dataspace Message

- - -
- - - - - - - - - - -
Header Message Name: Dataspace
Header Message Type: 0x0001
Length: Varies according to the number of - dimensions, as described in the following table.
Status: Required for dataset objects; - may not be repeated.
Description:The dataspace message describes the number of dimensions (in - other words, “rank”) and size of each dimension that - the data object has. This message is only used for datasets which - have a simple, rectilinear, array-like layout; datasets requiring - a more complex layout are not yet supported. -
Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Dataspace Message - Version 1 -
bytebytebytebyte
VersionDimensionalityFlagsReserved
Reserved

Dimension #1 SizeL

.
.
.

Dimension #n SizeL


Dimension #1 Maximum SizeL (optional)

.
.
.

Dimension #n Maximum SizeL (optional)


Permutation Index #1L (optional)

.
.
.

Permutation Index #nL (optional)

- - - - - -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Dataspace Message - Version 1 -
Field NameDescription

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 2 of the dataspace message dropped the optional - permutation index value support, as it was never implemented in the - HDF5 Library:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Dataspace Message - Version 2 -
bytebytebytebyte
VersionDimensionalityFlagsType

Dimension #1 SizeL

.
.
.

Dimension #n SizeL


Dimension #1 Maximum SizeL (optional)

.
.
.

Dimension #n Maximum SizeL (optional)

- - - - - -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Dataspace Message - Version 2 -
Field NameDescription

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: - - - - - - - - - - - - - - - - - - -
ValueDescription
0A scalar dataspace; in other words, - a dataspace with a single, dimensionless element. -
1A simple dataspace; in other words, - a dataspace with a rank greater than 0 and an - appropriate number of dimensions. -
2A 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. -

-
-
- - - - - -

IV.A.2.c. The Link Info Message

- - -
- - - - - - - - -
Header Message Name: Link Info
Header Message Type: 0x002
Length: Varies
Status: Optional; may not be - repeated.
Description:The link info message tracks variable information about the - current state of the links for a “new style” - group’s behavior. Variable information will be stored in - this message and constant information will be stored in the - Group Info message. -
Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Link Info -
bytebytebytebyte
VersionFlagsThis space inserted only to align table nicely

Maximum Creation Index (8 bytes, optional)


Fractal Heap AddressO


Address of v2 B-tree for Name IndexO


Address of v2 B-tree for Creation Order IndexO (optional)

- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Link Info -
Field NameDescription

Version

 -

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

-

Flags

This field determines various optional aspects of the link - info message: - - - - - - - - - - - - - - - - - - - -
BitDescription
0If set, creation order for the links is tracked. -
1If set, creation order for the links is indexed. -
2-7Reserved

- -

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.

-
-
- - -

IV.A.2.d. The Datatype Message

- - -
- - - - - - - - -
Header Message Name: Datatype
Header Message Type: 0x0003 -
Length: Variable
Status: Required for dataset or committed - datatype (formerly named datatype) objects; may not be repeated. -
Description:

The datatype message defines the datatype for each element - of a dataset or a common datatype for sharing between multiple - datasets. A datatype can describe an atomic type like a fixed- - or floating-point type or more complex types like a C struct - (compound datatype), array (array datatype), or C++ vector - (variable-length datatype).

-

Datatype messages that are part of a dataset object do not - describe how elements are related to one another; the dataspace - message is used for that purpose. Datatype messages that are part of - a committed datatype (formerly named datatype) message describe - a common datatype that can be shared by multiple datasets in the - file.

-
Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Datatype Message -
bytebytebytebyte
Class and VersionClass Bit Field, Bits 0-7Class Bit Field, Bits 8-15Class Bit Field, Bits 16-23
Size


Properties


-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Datatype Message -
Field NameDescription

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: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
VersionDescription
0Never used -
1Used by early versions of the library to encode - compound datatypes with explicit array fields. - See the compound datatype description below for - further details. -
2Used when an array datatype needs to be encoded. -
3Used when a VAX byte-ordered type needs to be - encoded. Packs various other datatype classes more - efficiently also. -
4Used to encode the revised reference datatype. -
5Used when a complex number datatype needs to be encoded. -

- -

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: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Fixed-Point
1Floating-Point
2 Time
3String
4Bit field
5Opaque
6Compound
7Reference
8Enumerated
9Variable-Length
10Array
11Complex

- -

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. -

-
-
- - -
-
- -

Class specific information for the Fixed-point Numbers class - (Class 0):

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Bits: Fixed-point Bit Field Description -
BitsMeaning

0

Byte Order. If zero, byte order is little-endian; - otherwise, byte order is big endian.

1, 2

Padding type. Bit 1 is the lo_pad bit and bit 2 - is the hi_pad bit. If a datum has unused bits at either - end, then the lo_pad or hi_pad bit is copied to those - locations.

3

Signed. If this bit is set then the fixed-point - number is in 2’s complement form.

4-23

Reserved (zero).

-
- -
-
- - - - - - - - - - - - - - -
- Layout: Fixed-point Property Description -
ByteByteByteByte
Bit OffsetBit Precision
-
- -
-
- - - - - - - - - - - - - - - - - -
- Fields: Fixed-point Property Description -
Field NameDescription

Bit Offset

 -

The bit offset of the first significant bit of the fixed-point - value within the datatype. The bit offset specifies the number - of bits “to the right of” the value (which are set to the - lo_pad bit value). -

-

Bit Precision

 -

The number of bits of precision of the fixed-point value - within the datatype. This value, combined with the datatype - element’s size and the Bit Offset field specifies the number - of bits “to the left of” the value (which are set to the - hi_pad bit value). -

-
-
- - -
-
- -

Class specific information for the Floating-point Numbers class - (Class 1):

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Bits: Floating-point Bit Field Description -
BitsMeaning

0, 6

Byte Order. These two non-contiguous bits specify the - “endianness” of the bytes in the datatype element. - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Bit 6Bit 0Description
00Byte order is little-endian -
01Byte order is big-endian -
10Reserved -
11Byte order is VAX-endian -

-

1, 2, 3

Padding type. Bit 1 is the low bits pad type, bit 2 - is the high bits pad type, and bit 3 is the internal bits - pad type. If a datum has unused bits at either end or between - the sign bit, exponent, or mantissa, then the value of bit - 1, 2, or 3 is copied to those locations.

4-5

Mantissa Normalization. This 2-bit bit field specifies - how the most significant bit of the mantissa is managed. - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0No normalization -
1The most significant bit of the mantissa is always set - (except for 0.0). -
2The most significant bit of the mantissa is not stored, - but is implied to be set. -
3Reserved. -

-

7

Reserved (zero).

8-15

Sign Location. This is the bit position of the sign - bit. Bits are numbered with the least significant bit zero.

16-23

Reserved (zero).

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Floating-point Property Description -
ByteByteByteByte
Bit OffsetBit Precision
Exponent LocationExponent SizeMantissa LocationMantissa Size
Exponent Bias
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Floating-point Property Description -
Field NameDescription

Bit Offset

 -

The bit offset of the first significant bit of the floating-point - value within the datatype. The bit offset specifies the number - of bits “to the right of” the value. -

-

Bit Precision

 -

The number of bits of precision of the floating-point value - within the datatype. -

-

Exponent Location

 -

The bit position of the exponent field. Bits are numbered with - the least significant bit number zero. -

-

Exponent Size

 -

The size of the exponent field in bits. -

-

Mantissa Location

 -

The bit position of the mantissa field. Bits are numbered with - the least significant bit number zero. -

-

Mantissa Size

 -

The size of the mantissa field in bits. -

-

Exponent Bias

 -

The bias of the exponent field. -

-
-
- - -
-
- -

Class specific information for the Time class (Class 2):

- - -
- - - - - - - - - - - - - - - - - -
- Bits: Time Bit Field Description -
BitsMeaning

0

Byte Order. If zero, byte order is little-endian; - otherwise, byte order is big endian.

1-23

Reserved (zero).

-
- -
-
- - - - - - - - - - - -
- Layout: Time Property Description -
ByteByte
Bit Precision
-
- -
-
- - - - - - - - - - - - -
- Fields: Time Property Description -
Field NameDescription

Bit Precision

 -

The number of bits of precision of the time value. -

-
-
- - -
- -

Class specific information for the Strings class (Class 3):

- - -
- - - - - - - - - - - - - - - - - - - - - - -
- Bits: String Bit Field Description -
BitsMeaning

0-3

Padding type. This four-bit value determines the - type of padding to use for the string. The values are: - - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Null Terminate: A zero byte marks the end of the - string and is guaranteed to be present after - converting a long string to a short string. When - converting a short string to a long string the value is - padded with additional null characters as necessary. -
1Null Pad: Null characters are added to the end of - the value during conversions from short values to long - values but conversion in the opposite direction simply - truncates the value. -
2Space Pad: Space characters are added to the end of - the value during conversions from short values to long - values but conversion in the opposite direction simply - truncates the value. This is the Fortran - representation of the string. -
3-15Reserved -

-

4-7

Character Set. The character set used to - encode the string. - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0ASCII character set encoding -
1UTF-8 character set encoding -
2-15Reserved -

-

8-23

Reserved (zero).

-
- -

There are no properties defined for the string class. -

- -
-
- -

Class specific information for the Bit Fields class (Class 4):

- -
- - - - - - - - - - - - - - - - - - - - - - -
- Bits: Bitfield Bit Field Description -
BitsMeaning

0

Byte Order. If zero, byte order is little-endian; - otherwise, byte order is big endian.

1, 2

Padding type. Bit 1 is the lo_pad type and bit 2 - is the hi_pad type. If a datum has unused bits at either - end, then the lo_pad or hi_pad bit is copied to those - locations.

3-23

Reserved (zero).

-
- -
-
- - - - - - - - - - - - - - -
- Layout: Bit Field Property Description -
ByteByteByteByte
Bit OffsetBit Precision
-
- -
-
- - - - - - - - - - - - - - - - -
- Fields: Bit Field Property Description -
Field NameDescription

Bit Offset

 -

The bit offset of the first significant bit of the bit field - within the datatype. The bit offset specifies the number - of bits “to the right of” the value. -

-

Bit Precision

 -

The number of bits of precision of the bit field - within the datatype. -

-
-
- - -
-
- -

Class specific information for the Opaque class (Class 5):

- -
- - - - - - - - - - - - - - - - - -
- Bits: Opaque Bit Field Description -
BitsMeaning

0-7

Length of ASCII tag in bytes.

8-23

Reserved (zero).

-
- -
-
- - - - - - - - - - - - - -
- Layout: Opaque Property Description -
ByteByteByteByte

ASCII Tag
-
-
- -
-
- - - - - - - - - - - -
- Fields: Opaque Property Description -
Field NameDescription

ASCII Tag

 -

This NUL-terminated string provides a description for the - opaque type. It is NUL-padded to a multiple of 8 bytes. -

-
-
- - -
-
- -

Class specific information for the Compound class (Class 6):

- -
- - - - - - - - - - - - - - - - - -
- Bits: Compound Bit Field Description -
BitsMeaning

0-15

Number of Members. This field contains the number - of members defined for the compound datatype. The member - definitions are listed in the Properties field of the data - type message.

16-23

Reserved (zero).

-
- - -

The Properties field of a compound datatype is a list of the - member definitions of the compound datatype. The member - definitions appear one after another with no intervening bytes. - The member types are described with a (recursively) encoded datatype - message.

- -

Note that the property descriptions are different for different - versions of the datatype version. Additionally note that the version - 0 datatype encoding is deprecated and has been replaced with later - encodings in versions of the HDF5 Library from the 1.4 release - onward.

- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Compound Properties Description for Datatype Version 1 -
ByteByteByteByte

Name

Byte Offset of Member
DimensionalityReserved (zero)
Dimension Permutation
Reserved (zero)
Dimension #1 Size (required)
Dimension #2 Size (required)
Dimension #3 Size (required)
Dimension #4 Size (required)

Member Type Message

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Compound Properties Description for Datatype Version 1 -
Field NameDescription

Name

 -

This NUL-terminated string provides a description for the - opaque type. It is NUL-padded to a multiple of 8 bytes. -

-

Byte Offset of Member

 -

This is the byte offset of the member within the datatype. -

-

Dimensionality

 -

If set to zero, this field indicates a scalar member. If set - to a value greater than zero, this field indicates that the - member is an array of values. For array members, the size of - the array is indicated by the ‘Size of Dimension n’ field in - this message. -

-

Dimension Permutation

 -

This field was intended to allow an array field to have - its dimensions permuted, but this was never implemented. - This field should always be set to zero. -

-

Dimension #n Size

 -

This field is the size of a dimension of the array field 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. -

-

Member Type Message

 -

This field is a datatype message describing the datatype of - the member. -

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - -
- Layout: Compound Properties Description for Datatype Version 2 -
ByteByteByteByte

Name

Byte Offset of Member

Member Type Message

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - -
- Fields: Compound Properties Description for Datatype Version 2 -
Field NameDescription

Name

 -

This NUL-terminated string provides a description for the - opaque type. It is NUL-padded to a multiple of 8 bytes. -

-

Byte Offset of Member

 -

This is the byte offset of the member within the datatype. -

-

Member Type Message

 -

This field is a datatype message describing the datatype of - the member. -

-
-
- - -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - -
- Layout: Compound Properties Description for Datatype Version 3 -
ByteByteByteByte

Name

Byte Offset of Member (variable size)

Member Type Message

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - -
- Fields: Compound Properties Description for Datatype Version 3 -
Field NameDescription

Name

This NUL-terminated string provides a description for the - opaque type. It is not NUL-padded to a multiple of 8 - bytes.

Byte Offset of Member

This is the byte offset of the member within the datatype. - The field size is the minimum number of bytes necessary, - based on the size of the datatype element. For example, a - datatype element size of less than 256 bytes uses a 1 byte - length, a datatype element size of 256-65535 bytes uses a - 2 byte length, and so on.

Member Type Message

This field is a datatype message describing the datatype of - the member.

-
- - -
-
- -

Class specific information for the Reference class (Class 7):

- -

Note that for region references, the stored data is - a Global Heap ID pointing to information - about the region stored in the global heap. -

- - -
- - - - - - - - - - - - - - - - - -
- Bits: Reference Bit Field Description for Datatype Version < 4 -
BitsMeaning

0-3

Type. This four-bit value contains the reference types which are supported for - backward compatibility. The values defined are: - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Object Reference (H5R_OBJECT1): A reference to another object in this - HDF5 file. -
1Dataset Region Reference (H5R_DATASET_REGION1): A reference to a region within - a dataset in this HDF5 file. -
2-15Reserved -

- -

4-23

Reserved (zero).

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - -
- Bits: Reference Bit Field Description for Datatype Version 4 -
BitsMeaning

0-3

Type. This four-bit value contains the revised reference types. - The values defined are: - - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
2Object Reference (H5R_OBJECT2): A reference to another object - in this file or an external file. -
3Dataset Region Reference (H5R_DATASET_REGION2): A reference to a region within - a dataset in this file or an external file. -
4Attribute Reference (H5R_ATTR): A reference to an attribute attached to an - object in this file or an external file. -
5-15Reserved -

- -

4-7

Version. This four-bit value contains the version for encoding - the revised reference types. The values defined are: - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Unused -
1The version for encoding the revised reference types: Object Reference (2), - Dataset Region Reference (3) and Attribute Reference (4). -
2-15Reserved -

- -

8-23

Reserved (zero).

-
- -

There are no properties defined for the reference class. -

- - -
-
- -

Class specific information for the Enumeration class (Class 8):

- -
- - - - - - - - - - - - - - - - - -
- Bits: Enumeration Bit Field Description -
BitsMeaning

0-15

Number of Members. The number of name/value - pairs defined for the enumeration type.

16-23

Reserved (zero).

-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - -
- Layout: Enumeration Property Description for Datatype Versions - 1 and 2 -
ByteByteByteByte

Base Type


Names


Values

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - -
- Fields: Enumeration Property Description for Datatype Versions - 1 and 2 -
Field NameDescription

Base Type

 -

Each enumeration type is based on some parent type, usually an - integer. The information for that parent type is described - recursively by this field. -

-

Names

 -

The name for each name/value pair. Each name is stored as a null - terminated ASCII string in a multiple of eight bytes. The names - are in no particular order. -

-

Values

 -

The list of values in the same order as the names. The values - are packed (no inter-value padding) and the size of each value - is determined by the parent type. -

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - -
- Layout: Enumeration Property Description for Datatype Version 3 -
ByteByteByteByte

Base Type


Names


Values

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - -
- Fields: Enumeration Property Description for Datatype Version 3 -
Field NameDescription

Base Type

 -

Each enumeration type is based on some parent type, usually an - integer. The information for that parent type is described - recursively by this field. -

-

Names

 -

The name for each name/value pair. Each name is stored as a null - terminated ASCII string, not padded to a multiple of - eight bytes. The names are in no particular order. -

-

Values

 -

The list of values in the same order as the names. The values - are packed (no inter-value padding) and the size of each value - is determined by the parent type. -

-
-
- - - -
- -

Class specific information for the Variable-length class (Class 9):

- -

Note that data with a variable length type is stored on the global heap. - Locations that would normally store the data directly (e.g. attribute message) - will instead contain a Global Heap ID. -

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Bits: Variable-length Bit Field Description -
BitsMeaning

0-3

Type. This four-bit value contains the type of - variable-length datatype described. The values defined are: - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Sequence: A variable-length sequence of any datatype. - Variable-length sequences do not have padding or - character set information. -
1String: A variable-length sequence of characters. - Variable-length strings have padding and character set - information. -
2-15Reserved -

- -

4-7

Padding type. (variable-length string only) - This four-bit value determines the type of padding - used for variable-length strings. The values are the same - as for the string padding type, as follows: - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Null terminate: A zero byte marks the end of a string - and is guaranteed to be present after converting a long - string to a short string. When converting a short string - to a long string, the value is padded with additional null - characters as necessary. -
1Null pad: Null characters are added to the end of the - value during conversion from a short string to a longer - string. Conversion from a long string to a shorter string - simply truncates the value. -
2Space pad: Space characters are added to the end of the - value during conversion from a short string to a longer - string. Conversion from a long string to a shorter string - simply truncates the value. This is the Fortran - representation of the string. -
3-15Reserved -

- -

This value is set to zero for variable-length sequences.

- -

8-11

Character Set. (variable-length string only) - This four-bit value specifies the character set - to be used for encoding the string: - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0ASCII character set encoding -
1UTF-8 character set encoding -
2-15Reserved -

- -

This value is set to zero for variable-length sequences.

- -

12-23

Reserved (zero).

-
- -
-
- - - - - - - - - - - - - - -
- Layout: Variable-length Property Description -
ByteByteByteByte

Parent Type Message

-
- -
-
- - - - - - - - - - - - -
- Fields: Variable-length Property Description -
Field NameDescription

Parent Type

 -

Each variable-length type is based on some parent type. - This field contains the datatype message describing that parent type. - In the case of nested variable-length types, this parent datatype message will - recursively contain all parent datatype messages. - - Variable-length strings are considered to have the parent type `H5T_NATIVE_UCHAR`. -

-
-
- - -
-
- -

Class specific information for the Array class (Class 10):

- -

There are no bit fields defined for the array class. -

- -

Note that the dimension information defined in the property for this - datatype class is independent of dataspace information for a dataset. - The dimension information here describes the dimensionality of the - information within a data element (or a component of an element, if the - array datatype is nested within another datatype) and the dataspace for a - dataset describes the size and locations of the elements in a dataset. -

- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Array Property Description for Datatype Version 2 -
ByteByteByteByte
DimensionalityReserved (zero)
Dimension #1 Size
.
.
.
Dimension #n Size
Permutation Index #1
.
.
.
Permutation Index #n

Base Type

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Array Property Description for Datatype Version 2 -
Field NameDescription

Dimensionality

 -

This value is the number of dimensions that the array has. -

-

Dimension #n Size

 -

This value is the size of the dimension of the array - 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. -

-

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. Currently, dimension - permutations are not supported, and these indices should - be set to the index position minus one. In other words, - the first dimension should be set to 0, the second dimension - should be set to 1, and so on. -

-

Base Type

 -

Each array type is based on some parent type. The - information for that parent type is described recursively by - this field. -

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Array Property Description for Datatype Version 3 -
ByteByteByteByte
DimensionalityThis space inserted only to align table nicely
Dimension #1 Size
.
.
.
Dimension #n Size

Base Type

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - -
- Fields: Array Property Description for Datatype Version 3 -
Field NameDescription

Dimensionality

 -

This value is the number of dimensions that the array has. -

-

Dimension #n Size

 -

This value is the size of the dimension of the array - 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. -

-

Base Type

 -

Each array type is based on some parent type. The - information for that parent type is described recursively by - this field. -

-
-
- -
-
- -

Class specific information for the Complex class (Class 11):

- -
- - - - - - - - - - - - - - - - - - - - - - -
- Bits: Complex Bit Field Description -
BitsMeaning

0

Homogeneous. If zero, each part of the complex number - datatype is a different floating point datatype (heterogeneous). - Otherwise, each part of the complex number datatype is the same - floating point datatype (homogeneous). Currently, only homogeneous - complex number datatypes are supported.

1,2

Complex number form. This two-bit value contains the type of - complex number datatype described. The values defined are: - - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Rectangular -
1Polar -
2Exponential -
3Reserved -

- -

Currently, only rectangular complex number datatypes are supported.

-

3-23

Reserved (zero).

-
- -
-
- - - - - - - - - - - - - -
- Layout: Complex Property Description -
ByteByteByteByte

Parent Type Message

-
- -
-
- - - - - - - - - - - -
- Fields: Complex Property Description -
Field NameDescription

Parent Type Message

 -

Each complex number type is based on a parent floating point type. - This field contains the datatype message describing that parent type. -

-
-
- - -

IV.A.2.e. The Data Storage - - Fill Value (Old) Message

- - -
- - - - - - - - -
Header Message Name: Fill Value - (old)
Header Message Type: 0x0004
Length: Varies
Status: Optional; may not be - repeated.
Description:

The fill value message stores a single data value which - is returned to the application when an uninitialized data element - is read from a dataset. The fill value is interpreted with the - same datatype as the dataset. If no fill value message is present - then a fill value of all zero bytes is assumed.

-

This fill value message is deprecated in favor of the - “new” fill value message (Message Type 0x0005) and - is only written to the file for forward compatibility with - versions of the HDF5 Library before the 1.6.0 version. - Additionally, it only appears for datasets with a user-defined - fill value (as opposed to the library default fill value or an - explicitly set “undefined” fill value).

-
Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - -
- Layout: Fill Value Message (Old) -
bytebytebytebyte
Size

Fill Value (optional, variable size)

-
- -
-
- - - - - - - - - - - - - - - - -
- Fields: Fill Value Message (Old) -
Field NameDescription

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. -

-
-
- - -

IV.A.2.f. The Data Storage - - Fill Value Message

- - -
- - - - - - - - -
Header Message Name: Fill - Value
Header Message Type: 0x0005
Length: Varies
Status: Required for dataset objects; - may not be repeated.
Description:The fill value message stores a single data value which is - returned to the application when an uninitialized data element - is read from a dataset. The fill value is interpreted with the - same datatype as the dataset.
Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Fill Value Message - Versions 1 and 2 -
bytebytebytebyte
VersionSpace Allocation TimeFill Value Write TimeFill Value Defined
Size (optional)

Fill Value (optional, variable size)

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Fill Value Message - Versions 1 and 2 -
Field NameDescription

Version

 -

The version number information is used for changes in the - format of the fill value message and is described here: - - - - - - - - - - - - - - - - - - - - - - -
VersionDescription
0Never used -
1Initial version of this message. -
2In this version, the Size and Fill Value fields are - only present if the Fill Value Defined field is set - to 1. -
3This 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: - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Not used. -
1Early allocation. Storage space for the entire dataset - should be allocated in the file when the dataset is - created. -
2Late allocation. Storage space for the entire dataset - should not be allocated until the dataset is written - to. -
3Incremental 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: - - - - - - - - - - - - - - - - - - -
ValueDescription
0On allocation. The fill value is always written to - the raw data storage when the storage space is allocated. -
1Never. The fill value should never be written to - the raw data storage. -
2Fill 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. -

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Fill Value Message - Version 3 -
bytebytebytebyte
VersionFlagsThis space inserted only to align table nicely
Size (optional)

Fill Value (optional, variable size)

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Fill Value Message - Version 3 -
Field NameDescription

Version

 -

The version number information is used for changes in the - format of the fill value message and is described here: - - - - - - - - - - - - - - - - - - - - - - -
VersionDescription
0Never used -
1Initial version of this message. -
2In this version, the Size and Fill Value fields are - only present if the Fill Value Defined field is set - to 1. -
3This 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: - - - - - - - - - - - - - - - - - - - - - - - - - - -
BitsDescription
0-1Space Allocation Time, with the same - values as versions 1 and 2 of the message. -
2-3Fill Value Write Time, with the same - values as versions 1 and 2 of the message. -
4Fill Value Undefined, indicating that the fill - value has been marked as “undefined” for this dataset. - Bits 4 and 5 cannot both be set. -
5Fill Value Defined, with the same values as - versions 1 and 2 of the message. - Bits 4 and 5 cannot both be set. -
6-7Reserved (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. -

-
-
- - -

IV.A.2.g. The Link Message

- - -
- - - - - - - - -
Header Message Name: Link
Header Message Type: 0x0006
Length: Varies
Status: Optional; may be - repeated.
Description:

This message encodes the information for a link in a - group’s object header, when the group is storing its links - “compactly”, or in the group’s fractal heap, - when the group is storing its links “densely”.

-

A group is storing its links compactly when the fractal heap - address in the Link Info - Message is set to the “undefined address” - value.

Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Link Message -
bytebytebytebyte
VersionFlagsLink type (optional)This space inserted only to align table nicely

Creation Order (8 bytes, optional)

Link Name Character Set (optional)Length of Link Name (variable size)This space inserted only to align table nicely
Link Name (variable size)

Link Information (variable size)

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Link Message -
Field NameDescription

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. - - - - - - - - - - - - - - - - - - - - - - - - - - -
BitsDescription
0-1Determines the size of the Length of Link Name - field. - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0The size of the Length of Link Name - field is 1 byte. -
1The size of the Length of Link Name - field is 2 bytes. -
2The size of the Length of Link Name - field is 4 bytes. -
3The size of the Length of Link Name - field is 8 bytes. -
-
2Creation 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. -
3Link 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. -
4Link 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-7Reserved (zero). -

- -

Link type

This is the link class type and can be one of the following - values: - - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0A hard link (should never be stored in the file) -
1A soft link. -
2-63Reserved for future HDF5 internal use. -
64An external link. -
65-255Reserved, 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: - - - - - - - - - - - - - - - -
ValueDescription
0ASCII character set encoding (this should never be stored - in the file) -
1UTF-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.
-

- -
-
- -

IV.A.2.h. The Data Storage - - External Data Files Message

- - -
- - - - - - - - -
Header Message Name: External - Data Files
Header Message Type: 0x0007
Length: Varies
Status: Optional; may not be - repeated.
Description:The external data storage message indicates that the data - for an object is stored outside the HDF5 file. The filename of - the object is stored as a Universal Resource Location (URL) of - the actual filename containing the data. An external file list - record also contains the byte offset of the start of the data - within the file and the amount of space reserved in the file - for that data.
Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: External File List Message -
bytebytebytebyte
VersionReserved (zero)
Allocated SlotsUsed Slots

Heap AddressO


Slot Definitions...

- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: External File List Message -
Field NameDescription

Version

 -

The version number information is used for changes in the format of - External Data Storage Message and is described here: - - - - - - - - - - - - - -
VersionDescription
0Never used.
1The 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.

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - -
- Layout: External File List Slot -
bytebytebytebyte

Name Offset in Local HeapL


Offset in External Data FileL


Data Size in External FileL

- - - - - -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - -
- Fields: External File List Slot -
Field NameDescription

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.

-
-
- - -

IV.A.2.i. The Data Layout Message

- - -
- - - - - - - - -
Header Message Name: Data Layout
Header Message Type: 0x0008
Length: Varies
Status: Required for datasets; may not - be repeated.
Description:The Data Layout message - describes how the elements of a multi-dimensional array are stored - in the HDF5 file. Four types of data layout are supported: -
    -
  1. Contiguous: The array is stored in one contiguous area of - the file. This layout requires that the size of the array be - constant: data manipulations such as chunking, compression, - checksums, or encryption are not permitted. The message stores - the total storage size of the array. The offset of an element - from the beginning of the storage area is computed as in a C - array.
    2. -
  2. Chunked: The array domain is regularly decomposed into - chunks, and each chunk is allocated and stored separately. This - layout supports arbitrary element traversals, compression, - encryption, and checksums (these features are described - in other messages). The message stores the size of a chunk - instead of the size of the entire array; the storage size of - the entire array can be calculated by traversing the chunk index - that stores the chunk addresses.
    3. -
  3. Compact: The array is stored in one contiguous block as - part of this object header message.
    4. -
  4. Virtual: This is only supported for version 4 of the Data - Layout message. The message stores information that is used to - locate the global heap collection containing the Virtual Dataset - (VDS) mapping information. The mapping associates the VDS to - the source dataset elements that are stored across a collection - of HDF5 files.
    5. -
Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Data Layout Message (Versions 1 and 2) -
bytebytebytebyte
VersionDimensionalityLayout ClassReserved (zero)
Reserved (zero)

Data AddressO (optional)

Dimension 1 Size
Dimension 2 Size
...
Dimension #n Size
Dataset Element Size (optional)
Compact Data Size (optional)

Compact Data... (variable size, optional)

- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Data Layout Message (Versions 1 and 2) -
Field NameDescription

Version

 -

The version number information is used for changes in the format of the data - layout message and is described here: - - - - - - - - - - - - - - - - - - - - -
VersionDescription
0Never used.
1Used by version 1.4 and before of the library to encode layout information. - Data space is always allocated when the data set is created.
2Used by version 1.6.[0,1,2] of the library to encode layout information. - Data space is allocated only when it is necessary.

-

Dimensionality

An array has a fixed dimensionality. This field - specifies the number of dimension size fields later in the - message. The value stored for chunked storage is 1 greater than - the number of dimensions in the dataset’s dataspace. - For example, 2 is stored for a 1 dimensional dataset. -

-

Layout Class

The layout class specifies the type of storage for the data - and how the other fields of the layout message are to be - interpreted. - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Compact Storage -
1Contiguous Storage -
2Chunked Storage -
-

-

Data Address

For contiguous storage, this is the address of the raw - data in the file. For chunked storage this is the address - of the v1 B-tree that is used to look up the addresses of the - chunks. This field is not present for compact storage. - If the version for this message is greater than 1, the address - may have the “undefined address” value, to indicate that - storage has not yet been allocated for this array.

-

Dimension #n Size

For contiguous and compact storage the dimensions define - the entire size of the array while for chunked storage they define - the size of a single chunk. In all cases, they are in units of - array elements (not bytes). The first dimension stored in the list - of dimensions is the slowest changing dimension and the last - dimension stored is the fastest changing dimension. -

-

Dataset Element Size

The size of a dataset element, in bytes. This field is only - present for chunked storage. -

-

Compact Data Size

This field is only present for compact data storage. - It contains the size of the raw data for the dataset array, in - bytes.

-

Compact Data

This field is only present for compact data storage. - It contains the raw data for the dataset array.

-
-
- -
-

Version 3 of this message re-structured the format into specific - properties that are required for each layout class.

- - -
- - - - - - - - - - - - - - - - - - - -
- Layout: Data Layout Message (Version 3) -
bytebytebytebyte
VersionLayout ClassThis space inserted only to align table nicely

Properties (variable size)

-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
- Fields: Data Layout Message (Version 3) -
Field NameDescription

Version

 -

The version number information is used for changes in the format of layout message - and is described here: - - - - - - - - - - -
VersionDescription
3Used by the version 1.6.3 and later of the library to store properties - for each layout class.

-

Layout Class

The layout class specifies the type of storage for the data - and how the other fields of the layout message are to be - interpreted. - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Compact Storage -
1Contiguous Storage -
2Chunked Storage -
-

-

Properties

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

-
- -
- -

Class-specific information for compact storage (layout class 0): (Note: The dimensionality information - is in the Dataspace message)

- - -
- - - - - - - - - - - - - - - - - - -
- Layout: Compact Storage Property Description -
bytebytebytebyte
SizeThis space inserted only to align table nicely

Raw Data... (variable size)

-
- -
-
- - - - - - - - - - - - - - - - -
- Fields: Compact Storage Property Description -
Field NameDescription

Size

This field contains the size of the raw data for the dataset - array, in bytes. -

-

Raw Data

This field contains the raw data for the dataset array.

-
- - -
- -

Class-specific information for contiguous storage (layout class 1): - (Note: The dimensionality information is in the Dataspace message)

- - -
- - - - - - - - - - - - - - - - - -
- Layout: Contiguous Storage Property Description -
bytebytebytebyte

AddressO


SizeL

- - - - - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
-
- -
-
- - - - - - - - - - - - - - - - -
- Fields: Contiguous Storage Property Description -
Field NameDescription

Address

This is the address of the raw data in the file. - The address may have the “undefined address” value, to indicate - that storage has not yet been allocated for this array.

Size

This field contains the size allocated to store the raw data, - in bytes. -

-
-
- - -
-

Class-specific information for chunked storage (layout class 2):

- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Chunked Storage Property Description -
bytebytebytebyte
DimensionalityThis space inserted only to align table nicely

AddressO

Dimension 0 Size
Dimension 1 Size
...
Dimension #n Size
Dataset Element Size
- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Chunked Storage Property Description -
Field NameDescription

Dimensionality

A chunk has a fixed dimensionality. This field specifies - the number of dimension size fields later in the message.

Address

This is the address of the v1 B-tree - that is used to look up the - addresses of the chunks that actually store portions of the array - data. The address may have the “undefined address” value, to - indicate that storage has not yet been allocated for this array.

Dimension #n Size

These values define the dimension size of a single chunk, in - units of array elements (not bytes). The first dimension stored in - the list of dimensions is the slowest changing dimension and the - last dimension stored is the fastest changing dimension. -

-

Dataset Element Size

The size of a dataset element, in bytes. -

-
-
- - -
- -

- Version 4 of this message is similar to version 3 but has - additional information for the virtual layout class as well as - indexing information for the chunked layout class.

- -
- - - - - - - - - - - - - - - - - - - -
- Layout: Data Layout Message (Version 4) -
bytebytebytebyte
VersionLayout ClassThis space inserted - only to align table nicely

Properties (variable size)

-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
- Fields: Data Layout Message (Version 4) -
Field NameDescription

Version

 -

The value for this field is 4 and is used by version 1.10.0 - and later of the library to store properties for each layout - class and indexing information for the chunked layout. -

-

Layout Class

The layout class specifies the type of storage for the data - and how the other fields of the layout message are to be - interpreted. - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Compact Storage -
1Contiguous Storage -
2Chunked Storage -
3Virtual Storage -
-

-

Properties

This variable-sized field encodes information specific to a - layout class as follows: - - - - - - - - - - - - - - - - - - - - - - - - - -
Layout ClassDescription
Compact StorageSee Compact Storage - Property Description for the version 3 -Data Layout message. -
Contiguous StorageSee Contiguous Storage - Property Description for the version 3 -Data Layout message. -
Chunked StorageSee Chunked Storage - Property Description below. -
Virtual StorageSee Virtual Storage - Property Description below. -
- -

-
- -
- -

Class-specific information for chunked storage (layout - class 2):

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Chunked Storage Property Description -
bytebytebytebyte
FlagsDimensionalityDimension Size Encoded LengthThis space inserted to align table nicely
Dimension 0 Size (variable size)
Dimension 1 Size (variable size)
...
Dimension #n Size (variable size)
Chunk Indexing TypeThis space inserted only to align table nicely
Indexing Type Information (variable size)

AddressO

- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Chunked Storage Property Description -
Field NameDescription

Flags

This is the chunked layout feature flag:

- - - - - - - - - - - - - - - - - -
ValueDescription
DONT_FILTER_PARTIAL_BOUND_CHUNKS (bit 0)Do not apply filter to a partial edge chunk. - -
SINGLE_INDEX_WITH_FILTER (bit 1)A filtered chunk for Single Chunk indexing. -
- -

Dimensionality

A chunk has fixed dimension. This field specifies - the number of Dimension Size fields later in the message.

Dimension Size Encoded Length

 -

This is the size in bytes used to encode Dimension Size. -

-

Dimension #n Size

These values define the dimension size of a single chunk, in - units of array elements (not bytes). The first dimension stored in - the list of dimensions is the slowest changing dimension and the - last dimension stored is the fastest changing dimension. -

-

Chunk Indexing Type

There are five indexing types used to look up addresses - of the chunks. For more information on each type, see - “Appendix C: Types of Indexes for - Dataset Chunks.” - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
1Single Chunk indexing type. -
2Implicit indexing type. -
3Fixed Array indexing type. -
4Extensible Array indexing type. -
5Version 2 B-tree indexing type. -
-

-

Indexing Type Information

This variable-sized field encodes information specific to - an indexing type. More information on what is encoded with - each type can be found below this table. -

-

-

Address

This is the address specific to an indexing type. - The address may be undefined if the chunk or index storage is not allocated yet. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
Single Chunk indexAddress of the single chunk.
Implicit indexAddress of the array of dataset chunks.
Fixed Array indexAddress of the index.
Extensible Array indexAddress of the index.
Version 2 B-tree indexAddress of the index.
- -

-
-
- -
- -
    -
  1. - - Index-specific information for Single Chunk: -
    2. - -

    The following information exists only when the chunk is filtered. - In other words, when DONT_FILTER_PARTIAL_BOUND_CHUNKS - (bit 0) is enabled in the field flags.

    - -
    - - - - - - - - - - - - - - - - - - -
    - Layout: Single Chunk Indexing Information -
    bytebytebytebyte

    Size of filtered chunkL

    Filters for chunk
    - - - - - -
      - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
    -
    - -
    -
    - - - - - - - - - - - - - - - - -
    - Fields: Single Chunk Indexing Information -
    Field NameDescription

    Size of filtered chunk

    This field is the size of a filtered chunk.

    Filters for chunk

    This field contains filters for the chunk.

    -
    -

    - -
    - -
  2. - - Index-specific information for Implicit: -
    3. - -
    - - - - - - - - - - - - - - -
    - Layout: Implicit Indexing Information -
    bytebytebytebyte
    - No specific indexing information
    -
    - -
    -
  3. - - Index-specific information for Fixed Array: -
    4. - -
    - - - - - - - - - - - - - - - -
    - Layout: Fixed Array Indexing Information -
    bytebytebytebyte
    Page BitsThis space inserted only to align table nicely
    -
    - -
    -
    - - - - - - - - - - - - -
    - Fields: Fixed Array Indexing Information -
    Field NameDescription

    Page Bits

    This field contains the number of bits needed to store the - maximum number of elements in a data block page.

    -
    -

    - -
    -
  4. - - Index-specific information for Extensible Array: -
    5. - -
    - - - - - - - - - - - - - - - - - - - - - -
    - Layout: Extensible Array Indexing Information -
    bytebytebytebyte
    Max BitsIndex ElementsMin PointersMin Elements
    Page BitsThis space inserted only to align table nicely
    -
    - -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    - Fields: Extensible Array Indexing Information -
    Field NameDescription

    Max Bits

    This field contains the number of bits needed to store the maximum number of elements - in the array. -

    -

    Index Elements

    This field contains the number of elements to store in the - index block. -

    -

    Min Pointers

    This field contains the minimum number of data block pointers - for a superblock. -

    -

    Min Elements

    This field contains the minimum number of elements per data block. -

    -

    Page Bits

    This field contains the number of bits needed to store the - maximum number of elements in a data block page. -

    -
    -
    -

    -
    - -
  5. - - Index-specific information for Version 2 B-tree: -
    6. - -
    - - - - - - - - - - - - - - - - - - - -
    - Layout: Version 2 B-tree Indexing Information -
    bytebytebytebyte
    Node Size
    Split PercentMerge Percent - This space inserted only to align table nicely
    -
    - -
    -
    - - - - - - - - - - - - - - - - - - - - - -
    - Fields: Version 2 B-tree Indexing Information -
    Field NameDescription

    Node Size

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

    -

    Split Percent

    This field is the percentage full of a B-tree node at which to split the node.

    Merge Percent

    This field is the percentage full of a B-tree node at which to merge the node.

    -
    -
- - - -
- -

- Class-specific information for virtual storage (layout class 3):

- -
- - - - - - - - - - - - - - - - - - -
- Layout: Virtual Storage Property Description -
bytebytebytebyte

AddressO

Index
- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
-
- -
-
- - - - - - - - - - - - - - - - -
- Fields: Virtual Storage Property Description -
Field NameDescription

Address

This is the address of the global heap collection where - the VDS mapping entries are stored. - See “Disk Format: Level 1F - - Global Heap Block for Virtual Datasets.” -

Index

This is the index of the data object within the global heap collection. -

-
-
- -

IV.A.2.j. The Bogus Message

- - -
- - - - - - - - -
Header Message Name: Bogus
Header Message Type: 0x0009
Length: 4 bytes
Status: For testing only; should never - be stored in a valid file.
Description:This message is used for testing the HDF5 Library’s - response to an “unknown” message type and should - never be encountered in a valid HDF5 file.
Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - -
- Layout: Bogus Message -
bytebytebytebyte
Bogus Value
-
- -
-
- - - - - - - - - - - -
- Fields: Bogus Message -
Field NameDescription

Bogus Value

 -

This value should always be: 0xdeadbeef.

-
-
- -

IV.A.2.k. The Group Info Message -

- - -
- - - - - - - - -
Header Message Name: Group Info
Header Message Type: 0x000A
Length: Varies
Status: Optional; may not be - repeated.
Description:

This message stores information for the constants defining - a “new style” group’s behavior. Constant - information will be stored in this message and variable - information will be stored in the - Link Info message.

-

Note: the “estimated entry” information below is - used when determining the size of the object header for the - group when it is created.

Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Group Info Message -
bytebytebytebyte
VersionFlagsLink Phase Change: Maximum Compact Value (optional)
Link Phase Change: Minimum Dense Value (optional)Estimated Number of Entries (optional)
Estimated Link Name Length of Entries (optional)This space inserted only to align table nicely
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Group Info Message -
Field NameDescription

Version

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

-

Flags

This is the group information flag with the following definition: - - - - - - - - - - - - - - - - - - - -
BitDescription
0If set, link phase change values are stored. -
1If set, the estimated entry information is non-default - and is stored. -
2-7Reserved

-

Link Phase Change: Maximum Compact Value

The is the maximum number of links to store “compactly” (in - the group’s object header).

-

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

-

Link Phase Change: Minimum Dense Value

This is the minimum number of links to store “densely” (in - the group’s fractal heap). The fractal heap’s address is - located in the Link Info - message.

-

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

-

Estimated Number of Entries

This is the estimated number of entries in groups.

-

If this field is not present, the default value of 4 - will be used for the estimated number of group entries.

-

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

-

Estimated Link Name Length of Entries

This is the estimated length of entry name.

-

If this field is not present, the default value of 8 - will be used for the estimated link name length of group entries.

-

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

-
-
- - -

IV.A.2.l. The Data Storage - Filter - Pipeline Message

- - -
- - - - - - - - -
Header Message Name: - Data Storage - Filter Pipeline
Header Message Type: 0x000B
Length: Varies
Status: Optional; may not be - repeated.
Description:

This message describes the filter pipeline which should - be applied to the data stream by providing filter identification - numbers, flags, a name, and client data.

-

This message may be present in the object headers of both - dataset and group objects. For datasets, it specifies the - filters to apply to raw data. For groups, it specifies the - filters to apply to the group’s fractal heap. Currently, - only datasets using chunked data storage use the filter - pipeline on their raw data.

Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Filter Pipeline Message - Version 1 -
bytebytebytebyte
VersionNumber of FiltersReserved (zero)
Reserved (zero)

Filter Description List (variable size)

-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
- Fields: Filter Pipeline Message - Version 1 -
Field NameDescription

Version

The version number for this message. This table - describes version 1.

Number of Filters

The total number of filters described in this - message. The maximum possible number of filters in a - message is 32.

Filter Description List

A description of each filter. A filter description - appears in the next table.

-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Filter Description - Version 1 -
bytebytebytebyte
Filter Identification ValueName Length
FlagsNumber Client Data Values

Name (variable size, optional)


Client Data (variable size, optional)

Padding (variable size, optional)
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Filter Description - Version 1 -
Field NameDescription

Filter Identification Value

 -

- This value, often referred to as a filter identifier, - is designed to be a unique identifier for the filter. - Values from zero through 32,767 are reserved for filters - supported by The HDF Group in the HDF5 Library and for - filters requested and supported by third parties. - Filters supported by The HDF Group are documented immediately - below. Information on 3rd-party filters can be found at - The HDF Group’s - - Registered Filters page.

- -

- To request a filter identifier, please contact - The HDF Group’s Help Desk at - The HDF Group Help Desk. - You will be asked to provide the following information:

-
    -
  1. Contact information for the developer requesting the - new identifier
    2. -
  2. A short description of the new filter
    3. -
  3. Links to any relevant information, including licensing - information
    4. -
-

- Values from 32768 to 65535 are reserved for non-distributed uses - (for example, internal company usage) or for application usage - when testing a feature. The HDF Group does not track or document - the use of the filters with identifiers from this range.

- -

- The filters currently in library version 1.8.0 are - listed below: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IdentificationNameDescription
0N/AReserved
1deflateGZIP deflate compression
2shuffleData element shuffling
3fletcher32Fletcher32 checksum
4szipSZIP compression
5nbitN-bit packing
6scaleoffsetScale and offset encoded values
-

Name Length

Each filter has an optional null-terminated ASCII name - and this field holds the length of the name including the - null termination padded with nulls to be a multiple of - eight. If the filter has no name then a value of zero is - stored in this field.

Flags

The flags indicate certain properties for a filter. The - bit values defined so far are: - - - - - - - - - - - - - - - -
BitDescription
0If set then the filter is an optional filter. - During output, if an optional filter fails it will be - silently skipped in the pipeline.
1-15Reserved (zero)

-

Number of Client Data Values

Each filter can store integer values to control - how the filter operates. The number of entries in the - Client Data array is stored in this field.

Name

If the Name Length field is non-zero then it will - contain the size of this field, padded to a multiple of eight. This - field contains a null-terminated, ASCII character string to serve - as a comment/name for the filter.

Client Data

This is an array of four-byte integers which will be - passed to the filter function. The Client Data Number of - Values determines the number of elements in the array.

Padding

Four bytes of zeroes are added to the message at this - point if the Client Data Number of Values field contains - an odd number.

-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - -
- Layout: Filter Pipeline Message - Version 2 -
bytebytebytebyte
VersionNumber of FiltersThis space inserted only to align table nicely

Filter Description List (variable size)

-
- -
-
- - - - - - - - - - - - - - - - - - - - - -
- Fields: Filter Pipeline Message - Version 2 -
Field NameDescription

Version

The version number for this message. This table - describes version 2.

Number of Filters

The total number of filters described in this - message. The maximum possible number of filters in a - message is 32.

Filter Description List

A description of each filter. A filter description - appears in the next table.

-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Filter Description - Version 2 -
bytebytebytebyte
Filter Identification ValueName Length (optional)
FlagsNumber Client Data Values

Name (variable size, optional)


Client Data (variable size, optional)

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Filter Description - Version 2 -
Field NameDescription

Filter Identification Value

 -

- This value, often referred to as a filter identifier, - is designed to be a unique identifier for the filter. - Values from zero through 32,767 are reserved for filters - supported by The HDF Group in the HDF5 Library and for - filters requested and supported by third parties. - Filters supported by The HDF Group are documented immediately - below. Information on 3rd-party filters can be found at - The HDF Group’s - - Registered Filters page.

- -

- To request a filter identifier, please contact - The HDF Group’s Help Desk at - The HDF Group Help Desk. - You will be asked to provide the following information:

-
    -
  1. Contact information for the developer requesting the - new identifier
    2. -
  2. A short description of the new filter
    3. -
  3. Links to any relevant information, including licensing - information
    4. -
-

- Values from 32768 to 65535 are reserved for non-distributed uses - (for example, internal company usage) or for application usage - when testing a feature. The HDF Group does not track or document - the use of the filters with identifiers from this range.

- -

- The filters currently in library version 1.8.0 are - listed below: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IdentificationNameDescription
0N/AReserved
1deflateGZIP deflate compression
2shuffleData element shuffling
3fletcher32Fletcher32 checksum
4szipSZIP compression
5nbitN-bit packing
6scaleoffsetScale and offset encoded values
-

Name Length

Each filter has an optional null-terminated ASCII name - and this field holds the length of the name including the - null termination padded with nulls to be a multiple of - eight. If the filter has no name then a value of zero is - stored in this field.

-

Filters with IDs less than 256 (in other words, filters - that are defined in this format documentation) do not store - the Name Length or Name fields. -

-

Flags

The flags indicate certain properties for a filter. The - bit values defined so far are: - - - - - - - - - - - - - - - -
BitDescription
0If set then the filter is an optional filter. - During output, if an optional filter fails it will be - silently skipped in the pipeline.
1-15Reserved (zero)

-

Number of Client Data Values

Each filter can store integer values to control - how the filter operates. The number of entries in the - Client Data array is stored in this field.

Name

If the Name Length field is non-zero, then it will - contain the size of this field, not padded to a multiple - of eight. This field contains a non-null-terminated, - ASCII character string to serve as a comment/name for the filter. -

-

Filters that are defined in this format documentation - such as deflate and shuffle do not store the Name - Length or Name fields. -

-

Client Data

This is an array of four-byte integers which will be - passed to the filter function. The Client Data Number of - Values determines the number of elements in the array.

-
-
- -

IV.A.2.m. The Attribute Message

- - -
- - - - - - - - -
Header Message Name: Attribute
Header Message Type: 0x000C
Length: Varies
Status: Optional; may be - repeated.
Description:

The Attribute message is used to store objects - in the HDF5 file which are used as attributes, or - “metadata” about the current object. An attribute - is a small dataset; it has a name, a datatype, a dataspace, and - raw data. Since attributes are stored in the object header, they - should be relatively small (in other words, less than 64KB). - They can be associated with any type of object which has an - object header (groups, datasets, or committed (named) - datatypes).

-

In 1.8.x versions of the library, attributes can be larger - than 64KB. See the - - “Special Issues” section of the Attributes chapter - in the HDF5 User’s Guide for more information.

-

Note: Attributes on an object must have unique names: - the HDF5 Library currently enforces this by causing the - creation of an attribute with a duplicate name to fail. - Attributes on different objects may have the same name, - however.

Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Attribute Message (Version 1) -
bytebytebytebyte
VersionReserved (zero)Name Size
Datatype SizeDataspace Size

Name (variable size)


Datatype (variable size)


Dataspace (variable size)


Data (variable size)

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Attribute Message (Version 1) -
Field NameDescription

Version

The version number information is used for changes in the format of the - attribute message and is described here: - - - - - - - - - - - - - - - -
VersionDescription
0Never used.
1Used by the library before version 1.6 to encode attribute message. - This version does not support shared datatypes.

-

Name Size

The length of the attribute name in bytes including the - null terminator. Note that the Name field below may - contain additional padding not represented by this - field.

Datatype Size

The length of the datatype description in the Datatype - field below. Note that the Datatype field may contain - additional padding not represented by this field.

Dataspace Size

The length of the dataspace description in the Dataspace - field below. Note that the Dataspace field may contain - additional padding not represented by this field.

Name

The null-terminated attribute name. This field is - padded with additional null characters to make it a - multiple of eight bytes.

Datatype

The datatype description follows the same format as - described for the datatype object header message. This - field is padded with additional zero bytes to make it a - multiple of eight bytes.

Dataspace

The dataspace description follows the same format as - described for the dataspace object header message. This - field is padded with additional zero bytes to make it a - multiple of eight bytes.

Data

The raw data for the attribute. The size is determined - from the datatype and dataspace descriptions. This - field is not padded with additional bytes.

-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Attribute Message (Version 2) -
bytebytebytebyte
VersionFlagsName Size
Datatype SizeDataspace Size

Name (variable size)


Datatype (variable size)


Dataspace (variable size)


Data (variable size)

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Attribute Message (Version 2) -
Field NameDescription

Version

The version number information is used for changes in the - format of the attribute message and is described here: - - - - - - - - - - -
VersionDescription
2Used by the library of version 1.6.x and after to encode - attribute messages. - This version supports shared datatypes. The fields of - name, datatype, and dataspace are not padded with - additional bytes of zero. -

-

Flags

This bit field contains extra information about - interpreting the attribute message: - - - - - - - - - - - - - - - - -
BitDescription
0If set, datatype is shared.
1If set, dataspace is shared.

-

Name Size

The length of the attribute name in bytes including the - null terminator.

Datatype Size

The length of the datatype description in the Datatype - field below.

Dataspace Size

The length of the dataspace description in the Dataspace - field below.

Name

The null-terminated attribute name. This field is not - padded with additional bytes.

Datatype

The datatype description follows the same format as - described for the datatype object header message. -

-

If the - Flag field indicates this attribute’s datatype is - shared, this field will contain a “shared message” encoding - instead of the datatype encoding. -

-

This field is not padded with additional bytes. -

-

Dataspace

The dataspace description follows the same format as - described for the dataspace object header message. -

-

If the - Flag field indicates this attribute’s dataspace is - shared, this field will contain a “shared message” encoding - instead of the dataspace encoding. -

-

This field is not padded with additional bytes.

-

Data

The raw data for the attribute. The size is determined - from the datatype and dataspace descriptions. -

-

This field is not padded with additional zero bytes. -

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Attribute Message (Version 3) -
bytebytebytebyte
VersionFlagsName Size
Datatype SizeDataspace Size
Name Character Set EncodingThis space inserted only to align table nicely

Name (variable size)


Datatype (variable size)


Dataspace (variable size)


Data (variable size)

-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Attribute Message (Version 3) -
Field NameDescription

Version

The version number information is used for changes in the - format of the attribute message and is described here: - - - - - - - - - - -
VersionDescription
3Used by the library of version 1.8.x and after to - encode attribute messages. - This version supports attributes with non-ASCII names. -

-

Flags

This bit field contains extra information about - interpreting the attribute message: - - - - - - - - - - - - - - - - -
BitDescription
0If set, datatype is shared.
1If set, dataspace is shared.

-

Name Size

The length of the attribute name in bytes including the - null terminator.

Datatype Size

The length of the datatype description in the Datatype - field below.

Dataspace Size

The length of the dataspace description in the Dataspace - field below.

Name Character Set Encoding

The character set encoding for the attribute’s name: - - - - - - - - - - - - - - - -
ValueDescription
0ASCII character set encoding -
1UTF-8 character set encoding -
-

-

Name

The null-terminated attribute name. This field is not - padded with additional bytes.

Datatype

The datatype description follows the same format as - described for the datatype object header message. -

-

If the - Flag field indicates this attribute’s datatype is - shared, this field will contain a “shared message” encoding - instead of the datatype encoding. -

-

This field is not padded with additional bytes. -

-

Dataspace

The dataspace description follows the same format as - described for the dataspace object header message. -

-

If the - Flag field indicates this attribute’s dataspace is - shared, this field will contain a “shared message” encoding - instead of the dataspace encoding. -

-

This field is not padded with additional bytes.

-

Data

The raw data for the attribute. The size is determined - from the datatype and dataspace descriptions. -

-

This field is not padded with additional zero bytes. -

-
-
- -

IV.A.2.n. The Object Comment - Message

- - -
- - - - - - - - -
Header Message Name: Object - Comment
Header Message Type: 0x000D
Length: Varies
Status: Optional; may not be - repeated.
Description:The object comment is designed to be a short description of - an object. An object comment is a sequence of non-zero - (\0) ASCII characters with no other formatting - included by the library.
Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - -
- Layout: Object Comment Message -
bytebytebytebyte

Comment (variable size)

-
- -
-
- - - - - - - - - - - -
- Fields: Object Comment Message -
Field NameDescription

Name

A null terminated ASCII character string.

-
- -

IV.A.2.o. The Object - Modification Time (Old) Message

- - -
- - - - - - - - -
Header Message Name: Object - Modification Time (Old)
Header Message Type: 0x000E
Length: Fixed
Status: Optional; may not be - repeated.
Description:

The object modification date and time is a timestamp - which indicates (using ISO-8601 date and time format) the last - modification of an object. The time is updated when any object - header message changes according to the system clock where the - change was posted. All fields of this message should be - interpreted as coordinated universal time (UTC).

-

This modification time message is deprecated in favor of - the “new” Object - Modification Time message and is no longer written to the - file in versions of the HDF5 Library after the 1.6.0 - version.

Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Modification Time Message (Old) -
bytebytebytebyte
Year
MonthDay of Month
HourMinute
SecondReserved
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Modification Time Message (Old) -
Field NameDescription

Year

The four-digit year as an ASCII string. For example, - 1998. -

Month

The month number as a two digit ASCII string where - January is 01 and December is 12.

Day of Month

The day number within the month as a two digit ASCII - string. The first day of the month is 01.

Hour

The hour of the day as a two digit ASCII string where - midnight is 00 and 11:00pm is 23.

Minute

The minute of the hour as a two digit ASCII string where - the first minute of the hour is 00 and - the last is 59.

Second

The second of the minute as a two digit ASCII string - where the first second of the minute is 00 - and the last is 59.

Reserved

This field is reserved and should always be zero.

-
- -

IV.A.2.p. The Shared Message Table - Message

- - -
- - - - - - - - -
Header Message Name: Shared Message - Table
Header Message Type: 0x000F
Length: Fixed
Status: Optional; may not be - repeated.
Description:This message is used to locate the table of shared object - header message (SOHM) indexes. Each index consists of information - to find the shared messages from either the heap or object header. - This message is only found in the superblock - extension.
Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Shared Message Table Message -
bytebytebytebyte
VersionThis space inserted only to align table nicely

Shared Object Header Message Table AddressO

Number of IndicesThis space inserted only to align table nicely
- - - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - -
- Fields: Shared Message Table Message -
Field NameDescription

Version

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

Shared Object Header Message Table Address

This field is the address of the master table for shared - object header message indexes.

-

Number of Indices

This field is the number of indices in the master table. -

-
- -

IV.A.2.q. The Object Header - Continuation Message

- - -
- - - - - - - - -
Header Message Name: Object Header - Continuation
Header Message Type: 0x0010
Length: Fixed
Status: Optional; may be - repeated.
Description:The object header continuation is the location in the file - of a block containing more header messages for the current data - object. This can be used when header blocks become too large or - are likely to change over time.
Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - -
- Layout: Object Header Continuation Message -
bytebytebytebyte

OffsetO


LengthL

- - - - - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - -
- Fields: Object Header Continuation Message -
Field NameDescription

Offset

This value is the address in the file where the - header continuation block is located.

Length

This value is the length in bytes of the header continuation - block in the file.

-
-
- -

The format of the header continuation block that this message points - to depends on the version of the object header that the message is - contained within. -

- -

- Continuation blocks for version 1 object headers have no special - formatting information; they are merely a list of object header - message info sequences (type, size, flags, reserved bytes and data - for each message sequence). See the description - of Version 1 Data Object Header Prefix. -

- -

Continuation blocks for version 2 object headers do have - special formatting information as described here - (see also the description of - Version 2 Data Object Header Prefix.): -

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 2 Object Header Continuation Block -
bytebytebytebyte
Signature
Header Message Type #1Size of Header Message Data #1Header Message #1 Flags
Header Message #1 Creation Order (optional)This space inserted only to align table nicely

Header Message Data #1

.
.
.
Header Message Type #nSize of Header Message Data #nHeader Message #n Flags
Header Message #n Creation Order (optional)This space inserted only to align table nicely

Header Message Data #n

Gap (optional, variable size)
Checksum
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 2 Object Header Continuation Block -
Field NameDescription

Signature

 -

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

-

Header Message #n Type

 -

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

Size of Header Message #n Data

 -

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

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. -

-
-
- -

IV.A.2.r. The Symbol Table - Message

- - -
- - - - - - - - -
Header Message Name: Symbol Table - Message
Header Message Type: 0x0011
Length: Fixed
Status: Required for - “old style” groups; may not be repeated.
Description:Each “old style” group has a v1 B-tree and a - local heap for storing symbol table entries, which are located - with this message.
Format of data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - -
- Layout: Symbol Table Message -
bytebytebytebyte

v1 B-tree AddressO


Local Heap AddressO

- - - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - -
- Fields: Symbol Table Message -
Field NameDescription

v1 B-tree Address

This value is the address of the v1 B-tree containing the - symbol table entries for the group.

Local Heap Address

This value is the address of the local heap containing - the link names for the symbol table entries for the group.

-
- -

IV.A.2.s. The Object - Modification Time Message

- - -
- - - - - - - - -
Header Message Name: Object - Modification Time
Header Message Type: 0x0012
Length: Fixed
Status: Optional; may not be - repeated.
Description:The object modification time is a timestamp which indicates - the time of the last modification of an object. The time is - updated when any object header message changes according to - the system clock where the change was posted.
Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - - -
- Layout: Modification Time Message -
bytebytebytebyte
VersionReserved (zero)
Seconds After UNIX Epoch
-
- -
-
- - - - - - - - - - - - - - - - -
- Fields: Modification Time Message -
Field NameDescription

Version

The version number is used for changes in the format of Object Modification Time - and is described here: - - - - - - - - - - - - - - - -
VersionDescription
0Never used.
1Used by Version 1.6.1 and after of the library to encode time. In - this version, the time is the seconds after Epoch.

-

Seconds After UNIX Epoch

A 32-bit unsigned integer value that stores the number of - seconds since 0 hours, 0 minutes, 0 seconds, January 1, 1970, - Coordinated Universal Time.

-
- -

IV.A.2.t. The B-tree - ‘K’ Values Message

- - -
- - - - - - - - -
Header Message Name: B-tree - ‘K’ Values
Header Message Type: 0x0013
Length: Fixed
Status: Optional; may not be - repeated.
Description:This message retrieves non-default ‘K’ values - for internal and leaf nodes of a group or indexed storage v1 - B-trees. This message is only found in the superblock - extension.
Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - - - - -
- Layout: B-tree ‘K’ Values Message -
bytebytebytebyte
VersionIndexed Storage Internal Node KThis space inserted only to align table nicely
Group Internal Node KGroup Leaf Node K
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: B-tree ‘K’ Values Message -
Field NameDescription

Version

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

-

Indexed Storage Internal Node K

This is the node ‘K’ value for each internal node of an - indexed storage v1 B-tree. See the description of this field - in version 0 and 1 of the superblock as well the section on - v1 B-trees. -

-

Group Internal Node K

This is the node ‘K’ value for each internal node of a group - v1 B-tree. See the description of this field in version 0 and - 1 of the superblock as well as the section on v1 B-trees. -

-

Group Leaf Node K

This is the node ‘K’ value for each leaf node of a group v1 - B-tree. See the description of this field in version 0 and 1 - of the superblock as well as the section on v1 B-trees. -

-
-
- -

IV.A.2.u. The Driver Info - Message

- - -
- - - - - - - - - -
Header Message Name: Driver - Info
Header Message Type: 0x0014
Length: Varies
Status: Optional; may not be - repeated.
- Description:This message contains information needed by the file driver - to reopen a file. This message is only found in the - superblock extension: see the - “Disk Format: Level 0C - Superblock Extension” - section for more information. For more information on the fields - in the driver info message, see the - “Disk Format: Level 0B - File Driver Info” - section; those who use the multi and family file drivers will - find this section particularly helpful.
Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Driver Info Message -
bytebytebytebyte
VersionThis space inserted only to align table nicely

Driver Identification
Driver Information SizeThis space inserted only to align table nicely


Driver Information (variable size)


-
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Driver Info Message -
Field NameDescription

Version

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

-

Driver Identification

This is an eight-byte ASCII string without null termination which - identifies the driver. -

-

Driver Information Size

The size in bytes of the Driver Information field of this - message.

-

Driver Information

Driver information is stored in a format defined by the file driver.

-
-
- -

IV.A.2.v. The Attribute Info - Message

- - -
- - - - - - - - -
Header Message Name: Attribute - Info
Header Message Type: 0x0015
Length: Varies
Status: Optional; may not be - repeated.
Description:This message stores information about the attributes on an - object, such as the maximum creation index for the attributes - created and the location of the attribute storage when the - attributes are stored “densely”.
Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Attribute Info Message -
bytebytebytebyte
VersionFlagsMaximum Creation Index (optional)

Fractal Heap AddressO


Attribute Name v2 B-tree AddressO


Attribute Creation Order v2 B-tree AddressO (optional)

- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Attribute Info Message -
Field NameDescription

Version

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

-

Flags

This is the attribute index information flag with the - following definition: - - - - - - - - - - - - - - - - - - - -
BitDescription
0If set, creation order for attributes is tracked. -
1If set, creation order for attributes is indexed. -
2-7Reserved

- -

Maximum Creation Index

The is the maximum creation order index value for the - attributes on the object.

-

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 - attributes. - Each attribute stored in the fractal heap is described by - the Attribute Message. -

-

Attribute Name v2 B-tree Address

This is the address of the version 2 B-tree to index the - names of densely stored attributes.

-

Attribute Creation Order v2 B-tree Address

This is the address of the version 2 B-tree to index the - creation order of densely stored attributes.

-

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

-
-
- -

IV.A.2.w. The Object Reference - Count Message

- - -
- - - - - - - - -
Header Message Name: Object Reference - Count
Header Message Type: 0x0016
Length: Fixed
Status: Optional; may not be - repeated.
Description:This message stores the number of hard links (in groups or - objects) pointing to an object: in other words, its - reference count.
Format of Data: See the tables - below.
- - -
- - - - - - - - - - - - - - - - - - -
- Layout: Object Reference Count -
bytebytebytebyte
VersionThis space inserted only to align table nicely
Reference count
-
- -
-
- - - - - - - - - - - - - - - - - -
- Fields: Object Reference Count -
Field NameDescription

Version

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

-

Reference Count

The unsigned 32-bit integer is the reference count for the - object. This message is only present in “version 2” - (or later) object headers, and if not present those object - header versions, the reference count for the object is assumed - to be 1.

-
-
- -
- -

IV.A.2.x. The File Space Info - Message

- -
- - - - - - - -

-

-
Header Message Name: File Space - Info
Header Message Type: 0x0017
Length: Fixed
Status: Optional; may not be - repeated.
- Description:This message stores the file space management information - that the library uses in handling file space - requests for the file. Version 0 of the message is used for release 1.10.0 only. - Version 1 of the message is used for release 1.10.1+. - There is no File Space Info message before release 1.10 as the library does - not track file space across multiple file opens. -

- Note that version 0 is deprecated starting release 1.10.1. - That means when the 1.10.1+ library opens an HDF5 file with a version 0 message, - the library will decode and map the message to version 1. - On file close, it will encode the message as a version 1 message. -

- The library uses the following three mechanisms to manage file space in an HDF5 file: -

    -
  • Free-space managers -
    They track free-space sections of various sizes in the file that are not currently - allocated. Each free-space manager corresponds to a file space type. - There are two main groups of file space types: metadata and raw data. - Metadata is further divided into five types: superblock, B-tree, global heap, - local heap, and object header. - See the description of Free-space - Manager as well the description of file space allocation types in - Appendix B -
    • -
  • Aggregators -
    The library manages two aggregators, one for metadata and one for raw data. - Aggregator is a contiguous block of free-space in the file. - The size of each aggregator is tunable via public routines - H5Pset_meta_block_size and H5Pset_small_data_block_size respectively. -
    • -
  • Virtual file drivers -
    The library's virtual file driver interface dispatches requests for additional - space to the allocation routine of the file driver associated with the file. - For example, if the sec2 file driver is being used, its allocation routine will - increase the size of the file to service the requests. -
    • -
-

- For release 1.10.0, the library derives the following four file space strategies - based on the mechanisms: -

    -
  • H5F_FILE_SPACE_ALL -
      -
    • Mechanisms used: free-space managers, aggregators, and virtual file drivers
      • -
    • Does not persist free-space across file opens
      • -
    • This strategy is the library default
      • -
    -
    • -
  • H5F_FILE_SPACE_ALL_PERSIST
    • -
      -
    • Mechanisms used: free-space managers, aggregators, and virtual file drivers
      • -
    • Persist free-space across file opens
      • -
    -
  • H5F_FILE_SPACE_AGGR_VFD
    • -
      -
    • Mechanisms used: aggregators and virtual file drivers
      • -
    • Does not persist free-space across file opens
      • -
    -
  • H5F_FILE_SPACE_VFD
    • -
      -
    • Mechanisms used: virtual file drivers
      • -
    • Does not persist free-space across file opens
      • -
    -
- For release 1.10.1+, the free-space manager mechanism is modified to handle paged aggregation - which aggregates small metadata and raw data allocations into constant-sized well-aligned pages - to allow efficient I/O accesses. - With the support of this feature, the library derives the following four file space strategies: -
    -
  • H5F_FSPACE_STRATEGY_FSM_AGGR
    • -
      -
    • Mechanisms used: free-space managers, aggregators, and virtual file drivers
      • -
    • This strategy is the library default
      • -
    -
  • H5F_FSPACE_STRATEGY_PAGE
    • -
      -
    • Mechanisms used: free-space managers with embedded paged aggregation and virtual file drivers
      • -
    -
  • H5F_FSPACE_STRATEGY_AGGR
    • -
      -
    • Mechanisms used: aggregators and virtual file drivers
      • -
    -
  • H5F_FSPACE_STRATEGY_NONE
    • -
      -
    • Mechanisms used: virtual file drivers
      • -
    -
- The default is not persisting free-space across file opens for the above four strategies. - User can use the public routine H5Pset_file_space_strategy to request - persisting free-space. -
Format of Data: See the tables - below.
-

-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: File Space Info - Version 0 -
bytebytebytebyte
VersionStrategyThresholdL

Free-space manager addressO for H5FD_MEM_SUPER


Free-space manager address0 for H5FD_MEM_BTREE


Free-space manager address0 for H5FD_MEM_DRAW


Free-space manager address0 for H5FD_MEM_GHEAP


Free-space manager address0 for H5FD_MEM_LHEAP


Free-space manager address0 for H5FD_MEM_OHDR

- - - - - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: File Space Info -
Field NameDescription

Version

This is version 0 of this message.

-

Strategy

This is the file space strategy used to manage file space. - There are four types: - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
1H5F_FILE_SPACE_ALL_PERSIST
2H5F_FILE_SPACE_ALL
3H5F_FILE_SPACE_AGGR_VFD
4H5F_FILE_SPACE_VFD

-

Threshold

This is the smallest free-space section size that the - free-space manager will track. -

Free-space manager addresses

These are the six free-space manager addresses for the - six file space allocation types: -

    -
  • H5FD_MEM_SUPER
    • -
  • H5FD_MEM_BTREE
    • -
  • H5FD_MEM_DRAW
    • -
  • H5FD_MEM_GHEAP
    • -
  • H5FD_MEM_LHEAP
    • -
  • H5FD_MEM_OHDR
    • -
- Note that these six fields exist only if the value for the field - “Strategy” is H5F_FILE_SPACE_ALL_PERSIST. -

-
-
-
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: File Space Info - Version 1 -
bytebytebytebyte
VersionStrategyPersisting free-spaceThis space inserted only to align table nicely
Free-space Section ThresholdL
File Space Page Size
Page-end Metadata thresholdThis space inserted only to align table nicely

EOA0


AddressO of small-sized free-space manager for H5FD_MEM_SUPER


AddressO of small-sized free-space manager for H5FD_MEM_BTREE


AddressO of small-sized free-space manager for H5FM_MEM_DRAW


AddressO of small-sized free-space manager for H5FD_MEM_GHEAP


AddressO of small-sized free-space manager for H5FD_MEM_LHEAP


AddressO of small-sized free-space manager for H5FD_MEM_OHDR


AddressO of large-sized free-space manager for H5FD_MEM_SUPER


AddressO of large-sized free-space manager for H5FD_MEM_BTREE


AddressO of large-sized free-space manager for H5FM_MEM_DRAW


AddressO of large-sized free-space manager for H5FD_MEM_GHEAP


AddressO of large-sized free-space manager for H5FD_MEM_LHEAP


AddressO of large-sized free-space manager for H5FD_MEM_OHDR

- - - - - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: File Space Info -
Field NameDescription

Version

This is version 1 of this message.

-

Strategy

This is the file space strategy used to manage file space. - There are four types: - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0H5F_FSPACE_STRATEGY_FSM_AGGR
1H5F_FSPACE_STRATEGY_PAGE
2H5F_FSPACE_STRATEGY_AGGR
3H5F_FSPACE_STRATEGY_NONE

-

Persisting free-space

True or false in persisting free-space. -

Free-space Section Threshold

This is the smallest free-space section size that the - free-space manager will track. -

File space page size

This is the file space page size, which is used when the paged aggregation feature - is enabled. -

Page-end metadata threshold

This is the smallest free-space section size at the end of a page that - the free-space manager will track. This is used when the paged aggregation feature - is enabled. -

EOA

The EOA before the allocation of free-space manager header and section info for the - self-referential free-space managers when persisting free-space. -
- Note that self-referential free-space managers are managers that involve file space - allocation for the managers' free-space header and section info. -

Addresses of small-sized free-space managers

These are the addresses of the six small-sized free-space managers for - the six file space allocation types: -

-
    -
  • H5FD_MEM_SUPER
    • -
  • H5FD_MEM_BTREE
    • -
  • H5FD_MEM_DRAW
    • -
  • H5FD_MEM_GHEAP
    • -
  • H5FD_MEM_LHEAP
    • -
  • H5FD_MEM_OHDR
    • -
- Note that these six fields exist only if the value for the field - “Persisting free-space” is true. - -

Addresses of large-sized free-space managers

These are the addresses of the six large-sized free-space managers for - the six file space allocation types: -

-
    -
  • H5FD_MEM_SUPER
    • -
  • H5FD_MEM_BTREE
    • -
  • H5FD_MEM_DRAW
    • -
  • H5FD_MEM_GHEAP
    • -
  • H5FD_MEM_LHEAP
    • -
  • H5FD_MEM_OHDR
    • -
- Note that these six fields exist only if the value for the field - “Persisting free-space” is true. - -
-
- -

- IV.B. Disk Format: Level 2B - Data Object Data Storage

- -

The data for an object is stored separately from its header - information in the file and may not actually be located in the HDF5 file - itself if the header indicates that the data is stored externally. The - information for each record in the object is stored according to the - dimensionality of the object (indicated in the dataspace header message). - Multi-dimensional array data is stored in C order; in other words, the - “last” dimension changes fastest.

- -

Data whose elements are composed of atomic datatypes are stored in IEEE - format, unless they are specifically defined as being stored in a different - machine format with the architecture-type information from the datatype - header message. This means that each architecture will need to [potentially] - byte-swap data values into the internal representation for that particular - machine.

- -

Data with a variable-length datatype is stored in the global heap - of the HDF5 file. Global heap identifiers are stored in the - data object storage.

- -

Data whose elements are composed of reference datatypes are stored in - several different ways depending on the particular reference type involved. - Object pointers are just stored as the offset of the object header being - pointed to with the size of the pointer being the same number of bytes as - offsets in the file.

- -

Dataset region references are stored as a heap-ID which points to - the following information within the file-heap: an offset of the object - pointed to, number-type information (same format as header message), - dimensionality information (same format as header message), sub-set start - and end information (in other words, a coordinate location for each), - and field start and end names (in other words, a [pointer to the] string - indicating the first field included and a [pointer to the] string name - for the last field).

- -

Data of a compound datatype is stored as a contiguous stream of the items - in the structure, with each item formatted according to its datatype. -

- Description of datatypes for variable-length, references and compound classes can be found - in Datatype Message. -

- Information about global heap and heap ID can be found in Global Heap. -

- For reference datatype, - see also the encoding description for Reference Encoding (Revised) and - Reference Encoding (Backward Compatibility) in Appendix D. -

- -

- V. Appendix A: Definitions

- -

Definitions of various terms used in this document are included in - this section.

- -
- - - - - - - - - - - - - - - - -
TermDefinition
Undefined AddressThe undefined - address for a file is a file address with all bits - set: in other words, 0xffff...ff.
Unlimited SizeThe unlimited size - for a size is a value with all bits set: in other words, - 0xffff...ff.
-
- - -

- VI. Appendix B: File Space Allocation Types

- -

There are six basic types of file space allocation as follows: -

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Basic Allocation TypeDescription
H5FD_MEM_SUPERFile space allocated for Superblock.
H5FD_MEM_BTREEFile space allocated for B-tree.
H5FD_MEM_DRAWFile space allocated for raw data.
H5FD_MEM_GHEAPFile space allocated for Global Heap.
H5FD_MEM_LHEAPFile space allocated for Local Heap.
H5FD_MEM_OHDRFile space allocated for Object Header.
-
- -
-

There are other file space allocation types that are mapped to the - above six basic types because they are similar in nature. - The mapping and the corresponding description are listed in the following two tables: -

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Basic Allocation TypeMapping of Allocation Types to Basic Allocation Types
H5FD_MEM_SUPERnone
H5FD_MEM_BTREEH5FD_MEM_SOHM_INDEX
H5FD_MEM_DRAWH5FD_MEM_FHEAP_HUGE_OBJ
H5FD_MEM_GHEAPnone
H5FD_MEM_LHEAPH5FD_MEM_FHEAP_DBLOCK, H5FD_MEM_FSPACE_SINFO
H5FD_MEM_OHDRH5FD_MEM_FHEAP_HDR, H5FD_MEM_FHEAP_IBLOCK, H5FD_MEM_FSPACE_HDR, H5FD_MEM_SOHM_TABLE
-
- -
-

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Allocation TypeDescription
H5FD_MEM_FHEAP_HDRFile space allocated for Fractal Heap Header.
H5FD_MEM_FHEAP_DBLOCKFile space allocated for Fractal Heap Direct Blocks.
H5FD_MEM_FHEAP_IBLOCKFile space allocated for Fractal Heap Indirect Blocks.
H5FD_MEM_FHEAP_HUGE_OBJFile space allocated for huge objects in the fractal heap.
H5FD_MEM_FSPACE_HDRFile space allocated for Free-space Manager Header.
H5FD_MEM_FSPACE_SINFOFile space allocated for Free-space Section List of the free-space manager.
H5FD_MEM_SOHM_TABLEFile space allocated for Shared Object Header Message Table.
H5FD_MEM_SOHM_INDEXFile space allocated for Shared Message Record List.
-
- -

VII. Appendix C: - Types of Indexes for Dataset Chunks

- -

For an HDF5 file without the latest format enabled, the library - uses the Version 1 B-tree to index dataset - chunks.

- -

For an HDF5 file with the latest format enabled, the library uses - one of the following five indexing types depending on a chunked - dataset’s dimension specification and the way it is extended. -

- - -

VII.A. The Single Chunk Index

 - -

The Single Chunk index can be used when the dataset fulfills - the following condition:

- - - -

The dataset has only one chunk, and the address of the single - chunk is stored in the version 4 Data Layout message. - See the Chunked Storage Property - Description layout and field description tables.

- - -

VII.B. The Implicit Index

 - -

The Implicit index can be used when the dataset fulfills - the following conditions:

- - - -

Since the dataset’s dimension sizes are known and storage space - is to be allocated early, an array of dataset chunks are allocated - based on the maximum dimension sizes when the dataset is created. - The base address of the array is stored in the version 4 - Data Layout message. See the - Chunked Storage Property - Description layout and field description tables. -

- -

When accessing a dataset chunk with a specified offset, the - address of the chunk in the array is computed as below:

- -

base address + (size of a chunk in bytes * chunk index - associated with the offset)

 - -

A chunk index starts at 0 and increases according to the - fastest changing dimension, then the next fastest, and so on. - - The chunk index for a dataset chunk offset is computed as below: -

    -
  1. Calculate the scaled offset for each dimension in - scaled_offset: -
    - 
    -        scaled_offset = chunk_offset/chunk_dims
-
    2. -
  2. Calculate the # of chunks for each dimension in - nchunks: -
    - 
    -        nchunks = (curr_dims + chunk_dims - 1)/chunk_dims
-
    3. - -
  3. Calculate the down chunks for each dimension in - down_chunks: -
    - 
    -        /* n is the # of dimensions */
-        for(i = (int)(n-1), acc = 1; i >= 0; i--) {
-        down_chunks[i] = acc;
-        acc *= nchunks[i];
-        }
-
    -
    4. - -
  4. Calculate the chunk index in chunk_index: -
    - 
    -        /* n is the # of dimensions */
-        for(u = 0, chunk_index = 0; u < n; u++)
-                                        chunk_index += down_chunks[u] * scaled_offset[u];
-
    -
    5. -
-

- For example, for a 2-dimensional dataset with - curr_dims[4,5] and chunk_dims[3,2], - there will be a total of 6 chunks, with 3 chunks in the fastest - changing dimension and 2 chunks in the slowest changing dimension. - See the figure below. - The chunk index for the chunk offset [3,4] - is computed as below: -

    - -
  1. scaled_offset[0] = 1, scaled_offset[1] = 2
    2. -
  2. nchunks[0] = 2, nchunks[1] = 3
    3. -
  3. down_chunks[0] = 3, down_chunks[1] = 1
    4. -
  4. chunk_index = 5
    5. -     -
- - - - - - - - - -
-
- Chunk Diagram
-
- Figure 3. Implicit index chunk diagram -
- - - - - - -

VII.C. The Fixed Array Index

 - -

The Fixed Array index can be used when the dataset fulfills - the following condition:

- - -

Since the maximum number of chunks is known, an array of - in-file-on-disk addresses based on the maximum number of chunks is - allocated when data is written to the dataset. To access a dataset - chunk with a specified offset, the - chunk index associated with the offset -is calculated. The index is mapped into the array to locate the -disk address for the chunk.

- -

The Fixed Array (FA) index structure provides space and speed - improvements in locating chunks over index structures that handle - more dynamic data accesses like a - Version 2 B-tree index. - The entry into the Fixed Array is the Fixed Array header which - contains metadata about the entries stored in the array. The - header contains a pointer to a data block which stores the array - of entries that describe the dataset chunks. For greater efficiency, - the array will be divided into multiple pages if the number of - entries exceeds a threshold value. The space for the data block - and possibly data block pages are allocated as a single contiguous - block of space.

- -

The content of the data block depends on whether paging is - activated or not. When paging is not used, elements that describe - the chunks are stored in the data block. If paging is turned on, - the data block contains a bitmap indicating which pages are - initialized. Then subsequent data block pages will contain the - entries that describe the chunks.

- -

An entry describes either a filtered or non-filtered dataset - chunk. The formats for both element types are described below. -

-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Fixed Array Header -
bytebytebytebyte
Signature
VersionClient IDEntry SizePage Bits

Max Num - EntriesL


Data Block - AddressO

Checksum
- - - - - - - - -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Fixed Array Header -
Field NameDescription

Signature

 -

The ASCII character string “FAHD” - is used to indicate the beginning of a Fixed Array header. - This gives file consistency checking utilities a better - chance of reconstructing a damaged file. -

-

Version

 -

This document describes version 0.

-

Client ID

 -

The ID for identifying the client of the - Fixed Array: - - - - - - - - - - - - - - - - - - - -
IDDescription
0Non-filtered dataset chunks -
1Filtered dataset chunks -
2+Reserved -
-

-

Entry Size

 -

The size in bytes of an entry in the Fixed Array. -

-

Page Bits

 -

The number of bits needed to store the maximum - number of entries in a - data block page.

-

Max Num Entries

 -

The maximum number of entries in the Fixed - Array.

-

Data Block Address

 -

The address of the data block in the Fixed Array. -

-

Checksum

 -

The checksum for the header.

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Fixed Array Data Block -
bytebytebytebyte
Signature
VersionClient IDThis space inserted - only to align table nicely

Header AddressO


Page Bitmap (variable size and - optional)


Elements (variable size and - optional)

Checksum
- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Fixed Array Data Block -
Field NameDescription

Signature

 -

The ASCII character string “FADB” - is used to indicate the beginning of a Fixed Array data - block. This gives file consistency checking utilities a - better chance of reconstructing a damaged file. -

-

Version

 -

This document describes version 0.

-

Client ID

 -

The ID for identifying the client of the - Fixed Array: - - - - - - - - - - - - - - - - - - - -
IDDescription
0Non-filtered dataset chunks -
1Filtered dataset chunks -
2+Reserved. -
-

-

Header Address

 -

The address of the Fixed Array header. Principally used - for file integrity checking. -

-

Page Bitmap

A bitmap indicating which data block pages are initialized.

-

Exists only if the data block is paged.

Elements

 -

Contains the elements stored in the data block - and exists only if the data block is not paged. - There are two element types: - - - - - - - - - - - - - - -
IDDescription
0Non-filtered - dataset chunks -
1Filtered dataset - chunks -
-

-

Checksum

 -

The checksum for the Fixed Array data block.

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - -
- Layout: Fixed Array Data Block Page -
bytebytebytebyte

Elements (variable - size)

Checksum
-
- -
-
- - - - - - - - - - - - - - - - - -
- Fields: Fixed Array Data Block Page -
Field NameDescription

Elements

 -

Contains the elements stored in the data block page. - There are two element types: - - - - - - - - - - - - - - -
IDDescription
0Non-filtered dataset chunks -
1Filtered dataset chunks -
-

-

Checksum

 -

The checksum for a Fixed Array data block page.

-
-
- -
-
-
- -
- - - - - - - - - - - - - - -
- Layout: Data Block Element for Non-filtered Dataset Chunk -
bytebytebytebyte

AddressO

- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
-
- -
-
- - - - - - - - - - - - -
- Fields: Data Block Element for Non-filtered Dataset Chunk -
Field NameDescription

Address

The address of the dataset chunk in the file. -

-
-
- - -
-
-
- -
- - - - - - - - - - - - - - - - - - - - - - -
- Layout: Data Block Element for Filtered Dataset Chunk -
bytebytebytebyte

AddressO


Chunk Size (variable size; at most - 8 bytes)

Filter Mask
- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - -
- Fields: Data Block Element for Filtered Dataset Chunk -
Field NameDescription

Address

The address of the dataset chunk in the file. -

-

Chunk Size

The size of the dataset chunk in bytes. -

-

Filter Mask

Indicates the filter to skip for the dataset chunk. Each - filter has an index number in the pipeline; if that filter is - skipped, the bit corresponding to its index is set. -

-
-
- - -

VII.D. The Extensible Array Index

 - -

The Extensible Array index can be used when the dataset - fulfills the following condition:

- - - -

The Extensible Array (EA) is a data structure that is used as a - chunk index in datasets where the dataspace has a single - unlimited dimension. In other words, one dimension is set to - H5S_UNLIMITED, and the other dimensions are any number - of fixed-size dimensions. The idea behind the extensible array is - that a particular data object can be located via a lightweight - indexing structure of fixed depth for a given address space. This - indexing structure requires only a few (2-3) file operations per - element lookup and gives good cache performance. Unlike the B-tree - structure, the extensible array is optimized for appends. Where a - B-tree would always add at the rightmost node under these - circumstances, either creating a deep tree (version 1) or requiring - expensive rebalances to correct (version 2), the extensible array - has already mapped out a pre-balanced internal structure. This - optimized internal structure is instantiated as needed when chunk - records are inserted into the structure.

- - - - - - - -

An Extensible Array consists of a header, an index block, - secondary blocks, data blocks, and (optional) data block pages. The - general scheme is that the index block is used to reference a - secondary block, which is, in turn, used to reference the data block - page where the chunk information is stored. The data blocks will - be paged for efficiency when their size passes a threshold value. - These pages are laid out contiguously on the disk after the data - block, are initialized as needed, and are tracked via bitmaps - stored in the secondary block. The number of secondary and data - blocks/pages in a chunk index varies as they are allocated as - needed and the first few are (conceptually) stored in parent - elements as an optimization.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Extensible Array Header -
bytebytebytebyte
Signature
VersionClient IDElement SizeMax Nelmts Bits
Index Blk ElmtsData Blk Min ElmtsSecondary Blk Min Data PtrsMax Data Blk Page Nelmts Bits

Num Secondary BlksL


Secondary Blk SizeL


Num Data BlksL


Data Blk SizeL


Max Index SetL


Num ElementsL


Index Block AddressO

Checksum
- - - - - - - - -
  - (Items marked with an ‘L’ in the above table are - of the size specified in the Size - of Lengths field in the superblock.) -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Extensible Array Header -
Field NameDescription

Signature

 -

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

-

Version

 -

This document describes version 0.

-

Client ID

 -

The ID for identifying the client of the - Fixed Array: - - - - - - - - - - - - - - - - - - - -
IDDescription
0Non-filtered dataset chunks -
1Filtered dataset chunks -
2+Reserved. -
-

-

Element Size

 -

The size in bytes of an element in the Extensible Array. -

-

Max Nelmts Bits

 -

The number of bits needed to store the - maximum number of elements in the Extensible Array.

-

Index Blk Elmts

 -

The number of elements to store in the index block. -

-

Data Blk Min Elmts

 -

The minimum number of elements per data block. -

-

Secondary Blk Min Data Ptrs

 -

The minimum number of data block pointers for a - secondary block. -

-

Max Dblk Page Nelmts Bits

 -

The number of bits needed to store the maximum number - of elements in a data block page. -

-

Num Secondary Blks

 -

The number of secondary blocks created. -

-

Secondary Blk Size

 -

The size of the secondary blocks created. -

-

Num Data Blks

 -

The number of data blocks created. -

-

Data Blk Size

 -

The size of the data blocks created. -

-

Max Index Set

 -

The maximum index set. -

-

Num Elmts

 -

The number of elements realized. -

-

Index Block Address

 -

The address of the index block. -

-

Checksum

 -

The checksum for the header.

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Extensible Array Index Block -
bytebytebytebyte
Signature
VersionClient IDThis space inserted - only to align table nicely

Header AddressO


Elements (variable size and - optional)


Data Block Addresses (variable - size and optional)


Secondary Block Addresses (variable - size and optional)

Checksum
- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Extensible Array Index Block -
Field NameDescription

Signature

 -

The ASCII character string “EAIB” - is used to indicate the beginning of an Extensible Array - Index Block. This gives file consistency checking utilities - a better chance of reconstructing a damaged file. -

-

Version

 -

This document describes version 0.

-

Client ID

 -

The client ID for identifying the user of the - Extensible Array: - - - - - - - - - - - - - - - - - - - -
IDDescription
0Non-filtered dataset chunks -
1Filtered dataset chunks -
2+Reserved. -
-

-

Header Address

 -

The address of the Extensible Array header. Principally - used for file integrity checking.

-

Elements

 -

Contains the elements that are stored directly in - the index block. An optimization to avoid unnecessary - secondary blocks. -
-
- There are two element types: - - - - - - - - - - - - - - -
IDDescription
0Non-filtered dataset chunks -
1Filtered dataset chunks -
-

-

Data Block Addresses

 -

Contains the addresses of the data blocks - that are stored directly in the Index Block. An - optimization to avoid unnecessary secondary blocks.

-

Secondary Block Addresses

 -

Contains the addresses of the secondary - blocks.

-

Checksum

 -

The checksum for the Extensible Array Index Block.

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Extensible Array Secondary Block -
bytebytebytebyte
Signature
VersionClient IDThis space inserted - only to align table nicely

Header AddressO


Block Offset (variable - size)


Page Bitmap (variable size and - optional)


Data Block Addresses (variable - size and optional)

Checksum
- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Extensible Array Secondary Block -
Field NameDescription

Signature

 -

The ASCII character string “EASB” - is used to indicate the beginning of an Extensible Array - Secondary Block. This gives file consistency checking utilities - a better chance of reconstructing a damaged file. -

-

Version

 -

This document describes version 0.

-

Client ID

 -

The ID for identifying the client of the - Extensible Array: - - - - - - - - - - - - - - - - - - - -
IDDescription
0Non-filtered dataset chunks -
1Filtered dataset chunks -
2+Reserved. -
-

-

Header Address

 -

The address of the Extensible Array header. Principally - used for file integrity checking.

-

Block Offset

 -

Stores the offset of the block in the array. -

-

Page Bitmap

 -

A bitmap indicating which - data block pages are initialized. -

- Exists only if the data block is paged. -

Data Block Addresses

 -

Contains the addresses of the data blocks - referenced by this secondary block.

-

Checksum

 -

The checksum for the Extensible Array - Secondary Block.

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Extensible Array Data Block -
bytebytebytebyte
Signature
VersionClient IDThis space inserted - only to align table nicely

Header AddressO


Block Offset (variable - size)


Elements (variable size and - optional)

Checksum
- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Extensible Array Data Block -
Field NameDescription

Signature

 -

The ASCII character string “EADB” - is used to indicate the beginning of an Extensible Array - data block. This gives file consistency checking utilities - a better chance of reconstructing a damaged file. -

-

Version

 -

This document describes version 0.

-

Client ID

 -

The ID for identifying the client of the - Extensible Array: - - - - - - - - - - - - - - - - - - - -
IDDescription
0Non-filtered dataset chunks -
1Filtered dataset chunks -
2+Reserved. -
-

-

Header Address

 -

The address of the Extensible Array header. Principally - used for file integrity checking. -

-

Block Offset

 -

The offset of the block in the array. -

Elements

 -

Contains the elements stored in the data block and - exists only if the data block is not paged. -
-
- There are two element types: - - - - - - - - - - - - - - -
IDDescription
0Non-filtered dataset chunks -
1Filtered dataset chunks -
-

-

Checksum

 -

The checksum for the Extensible Array data block.

-
-
- -
-
-
-
- - - - - - - - - - - - - - - - - - -
- Layout: Extensible Array Data Block Page -
bytebytebytebyte

Elements (variable - size)

Checksum
-
- -
-
- - - - - - - - - - - - - - - - - -
- Fields: Extensible Array Data Block Page -
Field NameDescription

Elements

 -

Contains the elements stored in the data block - page.

-

- There are two element types: - - - - - - - - - - - - - - -
IDDescription
0Non-filtered dataset chunks -
1Filtered dataset chunks -
-

-

Checksum

 -

The checksum for an Extensible Array data block - page.

-
-
- -
-
-
- -
- - - - - - - - - - - - - - -
- Layout: Data Block Element for Non-filtered Dataset Chunk -
bytebytebytebyte

AddressO

- - - - - -
-
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
-
- -
-
- - - - - - - - - - - - -
- Fields: Data Block Element for Non-filtered Dataset Chunk -
Field NameDescription

Address

The address of the dataset chunk in the file. -

-
-
-

- -
-
-
- -
- - - - - - - - - - - - - - - - - - - - - - -
- Layout: Data Block Element for Filtered Dataset Chunk -
bytebytebytebyte

AddressO


Chunk Size (variable size; at - most 8 bytes)

Filter Mask
- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
-
- -
-
- - - - - - - - - - - - - - - - - - - - - - -
- Fields: Data Block Element for Filtered Dataset Chunk -
Field NameDescription

Address

The address of the dataset chunk in the file. -

-

Chunk Size

The size of the dataset chunk in bytes. -

-

Filter Mask

Indicates the filter to skip for the dataset chunk. - Each filter has an index number in the pipeline; if that - filter is skipped, the bit corresponding to its index is set. -

-
-
- - -

VII.E. The Version 2 B-trees Index

 - -

The Version 2 B-trees index can be used when the dataset - fulfills the following condition:

- - - -

Version 2 B-trees can be used to index various objects in the - library. See “Version 2 B-trees” - for more information. The B-tree types 10 - and 11 record layouts are for - indexing dataset chunks.

- -

VIII. Appendix D: - Encoding for dataspace and reference

- - -

VIII.A. Dataspace Encoding

-H5Sencode is a public routine that encodes a dataspace description into a buffer while -H5Sdecode is the corresponding routine that decodes the description encoded in the buffer. -

- See the reference manual description for these two public routines. - -
-
-
-

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Dataspace Description for H5Sencode/H5Sdecode -
bytebytebytebyte
Dataspace IDEncode VersionSize of SizeThis space inserted - only to align table nicely

Size of Extent -



Dataspace Message - (variable size) -



Dataspace Selection - (variable size) -

- -
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Dataspace Description for H5Sencode/H5Sdecode -
Field NameDescription

Dataspace ID

 -

The datspace message ID which is 1.

-

Encode Version

 -

H5S_ENCODE_VERSION which is 0. -

-

Size of Size

 -

The number of bytes used to store the size of an object. -

-

Size of Extent

 -

Size of the dataspace message. -

-

Dataspace Message

 -

The dataspace message information. See - Dataspace Message.

-

-

Dataspace Selection

 -

The dataspace selection information. See - Dataspace Selection.

-
-
- - -
-
-
- -
- - - - - - - - - - - - - - - - - -
- Layout: Dataspace Selection -
bytebytebytebyte
Selection Type

Selection Info (variable - size)

-
- -
-
-
- - - - - - - - - - - - - - - - - - -
- Fields: Dataspace Selection -
Field NameDescription

Selection Type

 -

There are 4 types of selection: - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0H5S_SEL_NONE: Nothing selected -
1H5S_SEL_POINTS: Sequence of points selected -
2H5S_SEL_HYPER: Hyperslab selected -
3H5S_SEL_ALL: Entire extent selected -
-

Selection Info

 -

There are 4 types of selection info: - - - - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
0Selection info for H5S_SEL_NONE -
1Selection info for H5S_SEL_POINTS -
2Selection info for H5S_SEL_HYPER -
3Selection for H5S_SEL_ALL -
-

-
- - -
-
-
- -
- - - - - - - - - - - - - - - - - -
- Layout: Selection Info for H5S_SEL_NONE -
bytebytebytebyte
Version

Reserved (zero, 8 bytes)

-
- -
-
-
- - - - - - - - - - - -
- Fields: Selection Info for H5S_SEL_NONE -
Field NameDescription

Version

The version number for the H5S_SEL_NONE Selection Info. - The value is 1.

-
- - -
-
-
- -
- - - - - - - - - - - - - - - - - -
- Layout: Selection Info for H5S_SEL_POINTS -
bytebytebytebyte
Version


Points Selection Info (variable size) -


-
- -
-
-
- - - - - - - - - - - - - - - - - -
- Fields: Selection Info for H5S_SEL_POINTS -
Field NameDescription

Version

The version number for the H5S_SEL_POINTS Selection Info. - The value is either 1 or 2.

Points Selection Info

Depending on version: - - - - - - - - - - - - - - - - -
VersionDescription
1See Version 1 Points Selection Info -
2See Version 2 Points Selection Info -
-

-
- -
-
-
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 1 Points Selection Info -
bytebytebytebyte
Reserved (zero)
Length
Rank
Num Points
Point #1: coordinate #1
.
.
.
Point #1: coordinate #u
.
.
.
Point #n: coordinate #1
.
.
.
Point #n: coordinate #u
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 1 Points Selection Info -
Field NameDescription

Length

The size in bytes from Length to the end of the - selection info.

Rank

The number of dimensions.

Num Points

The number of points in the selection.

Point #n: coordinate #u

The array of points in the selection. -

The points selected are #1 to #n where n is Num Points. -

The list of coordinates for each point are #1 to #u where u is - Rank.

-
- - -
-
-
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 2 Points Selection Info -
bytebytebytebyte
Encode SizeThis space inserted only to align table nicely -
Rank
Num Points

(2, 4 or 8 bytes)

Point #1: coordinate #1

(2, 4 or 8 bytes)

.
.
.
Point #1: coordinate #u

(2, 4 or 8 bytes)

.
.
.
Point #n: coordinate #1

(2, 4 or 8 bytes)

.
.
.
Point #n: coordinate #u

(2, 4 or 8 bytes)

-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 2 Points Selection Info -
Field NameDescription

Encode Size

The size for encoding the points selection info which can be 2, 4 or 8 bytes. -

Rank

The number of dimensions.

Num Points

The number of points in the selection. -

The field Encode Size indicates the size of this field

Point #n: coordinate #u

The array of points in the selection. -

The points selected are #1 to #n where n is Num Points. -

The list of coordinates for each point are #1 to #u where u is - Rank. -

The field Encode Size indicates the size of this field

-
- - -
-
-
- -
- - - - - - - - - - - - - - - - - -
- Layout: Selection Info for H5S_SEL_HYPER -
bytebytebytebyte
Version

Hyperslab Selection Info - (variable size)

-
- -
-
-
- - - - - - - - - - - - - - - - - -
- Fields: Selection Info for H5S_SEL_HYPER -
Field NameDescription

Version

The version number for the H5S_SEL_HYPER selection info. - The value is 1, 2 or 3.

Hyperslab Selection Info

Depending on version: - - - - - - - - - - - - - - - - - - - - -
VersionDescription
1See Version 1 Hyperslab Selection Info. -
2See Version 2 Hyperslab Selection Info -
3See Version 3 Hyperslab Selection Info -
-

-
- -
-
-
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 1 Hyperslab Selection Info -
bytebytebytebyte
Reserved
Length
Rank
Num Blocks
Starting Offset #1 for Block #1
.
.
.
Starting Offset #n for Block #1
Ending Offset #1 for Block #1
.
.
.
Ending Offset #n for Block #1
.
.
.
.
.
.
.
.
.
Starting Offset #1 for Block #u
.
.
.
Starting Offset #n for Block #u
Ending Offset #1 for Block #u
.
.
.
Ending Offset #n for Block #u
-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 1 Hyperslab Selection Info -
Field NameDescription

Length

The size in bytes from the field Rank to the - end of the Selection Info.

Rank

The number of dimensions in the dataspace.

Num Blocks

The number of blocks in the selection.

Starting Offset #n for Block #u

The offset #n of the starting element in block #u. -

#n is from 1 to Rank. -

#u is from 1 to Num Blocks moving from the fastest - changing dimension to the slowest changing dimension. -

Ending Offset #n for Block #u

The offset #n of the ending element in block #u. -

#n is from 1 to Rank. -

#u is from 1 to Num Blocks moving from the fastest - changing dimension to the slowest changing dimension. -

-
- -
-
-
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 2 Hyperslab Selection Info -
bytebytebytebyte
FlagsThis space inserted - only to align table nicely
Length
Rank
Start #1 (8 bytes)

Stride #1 (8 bytes)

Count #1 (8 bytes)

Block #1 (8 bytes)

.
.
.
Start #n (8 bytes)

Stride #n (8 bytes)

Count #n (8 bytes)

Block #n (8 bytes)

-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 2 Hyperslab Selection Info -
Field NameDescription

Flags

This is a bit field with the following definition. - Currently, this is always set to 0x1. -

- - - - - - - - - - -
BitDescription
0If set, it is a regular hyperslab, otherwise, irregular. -
-

Length

The size in bytes from the field Rank to the - end of the Selection Info.

Rank

The number of dimensions in the dataspace.

Start #n

The offset of the starting element in the block. -

#n is from 1 to Rank. -

Stride #n

The number of elements to move in each dimension. -

#n is from 1 to Rank. -

Count #n

The number of blocks to select in each dimension. -

#n is from 1 to Rank. -

Block #n

The size (in elements) of each block in each dimension. -

#n is from 1 to Rank. -

-
- - - - -
-
-
- -
- - - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 3 Hyperslab Selection Info -
bytebytebytebyte
FlagsEncode SizeThis space inserted - only to align table nicely
Rank

Regular/Irregular Hyperslab Selection Info -

(variable size)

-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 3 Hyperslab Selection Info -
Field NameDescription

Flags

This is a bit field with the following definition: -

- - - - - - - - - - -
BitDescription
0If set, it is a regular hyperslab, otherwise, irregular. -
-

Encode Size

The size for encoding hyperslab selection info, which can 2, 4 or 8 bytes.

Rank

The number of dimensions in the dataspace.

Regular/Irregular Hyperslab Selection Info

This is the selection info for version 3 hyperslab which can be regular or irregular. -

If bit 0 of the field Flags is set, - See Version 3 Regular Hyperslab Selection Info -

Otherwise, see Version 3 Irregular Hyperslab Selection Info -

-
- - -
-
-
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 3 Regular Hyperslab Selection Info -
bytebytebytebyte
Start #1

(2, 4 or 8 bytes)

Stride #1

(2, 4 or 8 bytes)

Count #1

(2, 4 or 8 bytes)

Block #1

(2, 4 or 8 bytes)

.
.
.
Start #n

(2, 4 or 8 bytes)

Stride #n

(2, 4 or 8 bytes)

Count #n

(2, 4 or 8 bytes)

Block #n

(2, 4 or 8 bytes)

-
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Version 3 Regular Hyperslab Selection Info -
Field NameDescription

Start #n

The offset of the starting element in the block. -

#n is from 1 to Rank. -

The field Encode Size indicates the size of this field. -

Stride #n

The number of elements to move in each dimension. -

#n is from 1 to Rank. -

The field Encode Size indicates the size of this field. -

Count #n

The number of blocks to select in each dimension. -

#n is from 1 to Rank. -

The field Encode Size indicates the size of this field. -

Block #n

The size (in elements) of each block in each dimension. -

#n is from 1 to Rank. -

The field Encode Size indicates the size of this field. -

-
- -
-
-
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Version 3 Irregular Hyperslab Selection Info -
bytebytebytebyte
Num Blocks

(2, 4 or 8 bytes)

Starting Offset #1 for Block #1

(2, 4 or 8 bytes)

.
.
.
Starting Offset #n for Block #1

(2, 4 or 8 bytes)

Ending Offset #1 for Block #1

(2, 4 or 8 bytes)

.
.
.
Ending Offset #n for Block #1

(2, 4 or 8 bytes)

.
.
.
.
.
.
.
.
.
Starting Offset #1 for Block #u

(2, 4 or 8 bytes)

.
.
.
Starting Offset #n for Block #u

(2, 4 or 8 bytes)

Ending Offset #1 for Block #u

(2, 4 or 8 bytes)

.
.
.
Ending Offset #n for Block #u

(2, 4 or 8 bytes)

-
- -
-
-
- - - - - - - - - - - - - - - - - - -
- Fields: Version 3 Irregular Hyperslab Selection Info -

Num Blocks

The number of blocks in the selection. -

The field Encode Size indicates the size of this field

Starting Offset #n for Block #u

The offset #n of the starting element in block #u. -

#n is from 1 to Rank. -

#u is from 1 to Num Blocks moving from the fastest - changing dimension to the slowest changing dimension. -

The field Encode Size indicates the size of this field -

Ending Offset #n for Block #u

The offset #n of the ending element in block #u. -

#n is from 1 to Rank. -

#u is from 1 to Num Blocks moving from the fastest - changing dimension to the slowest changing dimension. -

The field Encode Size indicates the size of this field -

-
- - -
-
-
- -
- - - - - - - - - - - - - - - - - -
- Layout: Selection Info for H5S_SEL_ALL -
bytebytebytebyte
Version

Reserved (zero, - 8 bytes)

-
- -
-
-
- - - - - - - - - - - -
- Fields: Selection Info for H5S_SEL_ALL -
Field NameDescription

Version

The version number for the H5S_SEL_ALL Selection Info; - the value is 1.

-
- - -

VIII.B. Reference Encoding (Revised)

 -

-
- For the following reference type, - the Reference Header and Reference Block are stored together as the dataset's raw data: -

-

- For the following reference types, - the Reference Header plus the Global Heap ID are stored - as the dataset's raw data in the file. - The global heap ID is used to locate the Reference Block stored in the global heap: -

-
-
- -
- - - - - - - - - - - - - - - - -
- Layout: Reference Header -
bytebytebytebyte
Reference TypeFlagsThis space inserted - only to align table nicely
- -
- -
-
-
- - - - - - - - - - - - - - - - - -
- Fields: Reference Header -
Field NameDescription

Reference Type

 -

There are 3 types of references: - - - - - - - - - - - - - - - - - - - - - -
ValueDescription
2H5R_OBJECT2: Object Reference -
3H5R_DATASET_REGION2: Dataset Region Reference -
4H5R_ATTR: Attribute Reference -
- -

Flags

This field describes the reference: - - - - - - - - - - - - - - -
BitDescription
0If set, the reference is to an external file. -
1-7Reserved

- -
-
- -
-
-
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Layout: Reference Block -
bytebytebytebyte
Token SizeThis space inserted - only to align table nicely


Token - (variable size)


Length of External File NameThis space inserted - only to align table nicely


External File Name - (variable size)


Size of Dataspace Selection
Rank of Dataspace Selection


Dataspace Selection Information - (variable size)


Length of Attribute Name This space inserted - only to align table nicely


Attribute Name - (variable size)


- -
- -
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Fields: Reference Block -
Field NameDescription

Token size

This is the size of the token for the object. -

Token

 -

- This is the token for the object. -

-

Length of External File Name

This is the length for the external file name. -

This field exists if bit 0 of flags is set.

-

-

External File Name

This is the name of the external file being referenced.

-

-

This field exists if bit 0 of flags is set.

-

Dataspace Selection Information

See Dataspace Selection.

-

-

This field exists if the Reference Type is H5R_DATASET_REGION2.

-

Length of Attribute Name

This is the length of the attribute name. -

This field exists if the Reference Type is H5R_ATTRIBUTE.

-

Attribute Name

This is the name of the attribute being referenced. -

This field exists if the Reference Type is H5R_ATTRIBUTE.

-
-
- -
-
-
- - - -

VIII.C. Reference Encoding (Backward Compatibility)

 -

-
- The two references described below are maintained to preserve compatibility with previous versions of the library. -

- For the following reference type, - the reference encoding is stored as the dataset's raw data in the file: -

-

- For the following reference type, - the Global Heap ID is stored as the dataset's raw data in the file. - The global heap ID is used to locate the reference encoding - stored in the global heap: -

- -
-
-
- - - - - - - - - - - - - - -
- Layout: Reference for H5R_OBJECT1 -
bytebytebytebyte

Object AddressO

- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
-
- - - - - - - - - - - - -
- Fields: Reference for H5R_OBJECT1 -
Field NameDescription

Object Address

 -

Address of the object being referenced -

-
- -
-
-
- -
- - - - - - - - - - - - - - - - - - -
- Layout: Reference for H5R_DATASET_REGION1 -
bytebytebytebyte

Object AddressO



Dataspace Selection Information - (variable size)


- - - - - -
  - (Items marked with an ‘O’ in the above table are - of the size specified in the Size - of Offsets field in the superblock.) -
- -
- -
-
-
- - - - - - - - - - - - - - - - - -
- Fields: Reference for H5R_DATASET_REGION1 -
Field NameDescription

Object Address

This is the address of the object being referenced. -

Dataspace Selection Information

This is the dataspace selection for the object being referenced. - See Dataspace Selection.

-

-
-
- -
-
-
- -
- -