From 91cf10156a65a96860cea965df74a5adecf3e4e8 Mon Sep 17 00:00:00 2001 From: Allen Byrne <50328838+byrnHDF@users.noreply.github.com> Date: Tue, 28 Feb 2023 19:08:47 -0600 Subject: 1.12 Merge doxygen plist tables changes #2470 from develop (#2505) * Merge doxygen plist tables changes #2470 from develop * Add new/moved files * More add new/moved files * Doxy corrections --- doc/branches-explained.md | 31 +- doxygen/Doxyfile.in | 51 +- doxygen/dox/MetadataCachingInHDF5.dox | 2 +- doxygen/dox/Overview.dox | 2 +- doxygen/dox/PredefinedDatatypeTables.dox | 22 + doxygen/dox/ReferenceManual.dox | 152 +- doxygen/dox/ViewTools.dox | 8 +- doxygen/dox/cookbook/Accessibility.dox | 2 +- doxygen/dox/cookbook/Attributes.dox | 2 +- doxygen/dox/cookbook/Files.dox | 2 +- doxygen/dox/cookbook/Performance.dox | 2 +- doxygen/dox/high_level/extension.dox | 11 +- doxygen/examples/H5.format.2.0.html | 26718 +++++++++++----------- doxygen/examples/H5.format.html | 17 +- doxygen/examples/H5R_examples.c | 171 + doxygen/examples/VFL.html | 11 +- doxygen/examples/core_menu.md | 65 - doxygen/examples/fortran_menu.md | 73 - doxygen/examples/high_level_menu.md | 30 - doxygen/examples/java_menu.md | 84 - doxygen/examples/menus/core_menu.md | 69 + doxygen/examples/menus/fortran_menu.md | 73 + doxygen/examples/menus/high_level_menu.md | 30 + doxygen/examples/menus/java_menu.md | 84 + doxygen/examples/tables/fileDriverLists.dox | 139 + doxygen/examples/tables/predefinedDatatypes.dox | 629 + doxygen/examples/tables/propertyLists.dox | 955 + doxygen/examples/tables/volAPIs.dox | 637 + doxygen/hdf5_header.html | 2 +- doxygen/hdf5doxy_layout.xml | 9 +- src/H5Amodule.h | 2 +- src/H5Dmodule.h | 315 +- src/H5Dpublic.h | 6 +- src/H5ESpublic.h | 14 +- src/H5FDmpio.h | 6 +- src/H5FDpublic.h | 30 +- src/H5Fmodule.h | 298 +- src/H5Gmodule.h | 97 +- src/H5Gpublic.h | 20 +- src/H5Lpublic.h | 16 +- src/H5MMpublic.h | 2 - src/H5Mpublic.h | 3 + src/H5Opublic.h | 2 +- src/H5PLextern.h | 2 +- src/H5PLmodule.h | 2 +- src/H5PLpublic.h | 2 +- src/H5Pmodule.h | 155 +- src/H5Ppublic.h | 13 +- src/H5Tmodule.h | 34 +- src/H5Tpublic.h | 2 +- src/H5VLmodule.h | 24 +- 51 files changed, 16762 insertions(+), 14366 deletions(-) create mode 100644 doxygen/dox/PredefinedDatatypeTables.dox create mode 100644 doxygen/examples/H5R_examples.c delete mode 100644 doxygen/examples/core_menu.md delete mode 100644 doxygen/examples/fortran_menu.md delete mode 100644 doxygen/examples/high_level_menu.md delete mode 100644 doxygen/examples/java_menu.md create mode 100644 doxygen/examples/menus/core_menu.md create mode 100644 doxygen/examples/menus/fortran_menu.md create mode 100644 doxygen/examples/menus/high_level_menu.md create mode 100644 doxygen/examples/menus/java_menu.md create mode 100644 doxygen/examples/tables/fileDriverLists.dox create mode 100644 doxygen/examples/tables/predefinedDatatypes.dox create mode 100644 doxygen/examples/tables/propertyLists.dox create mode 100644 doxygen/examples/tables/volAPIs.dox diff --git a/doc/branches-explained.md b/doc/branches-explained.md index 22b9c8f..5b55ec7 100644 --- a/doc/branches-explained.md +++ b/doc/branches-explained.md @@ -8,34 +8,33 @@ We encourage code contributors to check the status of their commits. If you have ## `develop` Develop is the main branch whose source code always reflects a state with the latest delivered development changes for the next major release of HDF5. -This is also considered the integration branch, as **all** new features are integrated into this branch from respective feature branches. +This is also considered the integration branch, as **all** new features are integrated into this branch from respective feature branches. Although +develop is considered an integration branch, it is not an unstable branch. All code merged to develop is expected to pass all GitHub actions and daily tests. ## `Maintenance branches` - -Each currently supported release-line of HDF5 (e.g. 1.8.x, 1.10.x, 1.12.x) has a support branch with the name 1_8, 1_10, 1_12. +Each currently supported release line of HDF5 (e.g. 1.8.x, 1.10.x, 1.12.x) has an associated branch with the name hdf5\_1\_10, etc.. Maintenance branches are similar to the develop branch, except the source code in a maintenance branch always reflects a state with the latest delivered development changes for the next **maintenance** release of that particular supported release-line of HDF5. **Some** new features will be integrated into a release maintenance branch, depending on whether or not those features can be introduced in minor releases. Maintenance branches are removed when a release-line is retired from support. +## `Release branches` +Release branches are used to prepare a new production release. They are primarily used to allow for last minute dotting of i's and crossing of t's +(things like setting the release version, finalizing release notes, and generating Autotools files) and do not include new development. +They are created from the maintenance branch at the time of the maintenance release and have +names like hdf5\_1\_10\_N, where N is the minor release number. Once the release is done it is tagged, with a slightly different format: hdf5-1\_\10\_N. +Release branches are deleted after the tag has been created. If we have to create a patch version of a release (which is rare), we create a branch off of the tag. + ## `feature/*` Feature branches are temporary branches used to develop new features in HDF5. Feature branches branch off of develop and exist as long as the feature is under development. When the feature is complete, the branch is merged back into develop, as well as into any support branches in which the change will be included, and then the feature branch is removed. -## `release/*` -Release branches are used to prepare a new production release. They are primarily used to allow for last minute dotting of i's and crossing of t's -(things like setting the release version, finalizing release notes, et cetera) and do not include new development. -They are created from the maintenance branch at the time of the maintenance release and have -names 1_8_N, 1_10_N, 1_12_N, where N is the minor release number. Once the release is done it is tagged. -Patches can be applied to the release branch for patch releases that are treated as "scaled down" maintenance releases as defined by Release coordinator. - -## `1.X/master/*` where X is 8, 10 or 12 -These branches are used to tag 1.X.* maintenance releases. +Ideally, all feature branches should contain a BRANCH.md file in the root directory that explains the purpose of the branch, contact information for the person responsible, and, if possible, some clues about the branch's life cycle (so we have an idea about when it can be deleted, merged, or declared inactive). -## `inactive//*` -These branches are for experimental features that were developed in the past and have not been merged to develop, and are not under active development. The features -can be out of sync with the develop branch. +Minor bug fixes and refactoring work usually takes place on personal forks, not feature branches. -This document was last updated on March 16, 2021 +## `inactive/*` +These branches are for experimental features that were developed in the past, have not been merged to develop, and are not under active development. The exception to this is that some feature branches are labeled inactive and preserved for a short time after merging to develop. Integration branches are usually not kept in sync with the develop branch. +As for feature branches, inactive branches should have a BRANCH.md file as described above. diff --git a/doxygen/Doxyfile.in b/doxygen/Doxyfile.in index ce08db2..d9b0fe9 100644 --- a/doxygen/Doxyfile.in +++ b/doxygen/Doxyfile.in @@ -1,4 +1,4 @@ -# Doxyfile 1.8.18 +# Doxyfile # This file describes the settings to be used by the documentation system # doxygen (www.doxygen.org) for a project. @@ -853,31 +853,20 @@ INPUT_ENCODING = UTF-8 # C comment), *.py, *.pyw, *.f90, *.f95, *.f03, *.f08, *.f18, *.f, *.for, *.vhd, # *.vhdl, *.ucf, *.qsf and *.ice. -FILE_PATTERNS = H5*public.h \ - H5*module.h \ - H5FDcore.h \ - H5FDdirect.h \ - H5FDfamily.h \ - H5FDhdfs.h \ - H5FDlog.h \ - H5FDmirror.h \ - H5FDmpi.h \ - H5FDmpio.h \ - H5FDmulti.h \ - H5FDros3.h \ - H5FDsec2.h \ - H5FDsplitter.h \ - H5FDstdio.h \ - H5FDwindows.h \ - H5VLconnector.h \ - H5VLconnector_passthru.h \ - H5VLnative.h \ - H5Zdevelop.h \ - H5version.h \ - H5*.java \ - HDF*.java \ - *.F90 \ - *.dox +FILE_PATTERNS = H5*public.h H5*module.h H5*develop.h H5FD*.h \ + H5VLconnector.h H5VLconnector_passthru.h H5VLnative.h H5PLextern.h \ + H5Zdevelop.h \ + H5version.h \ + H5*.java \ + HDF*.java \ + *.F90 \ + *.dox \ + H5Cpp.h H5AbstractDs.h H5AtomType.h H5Attribute.h H5CommonFG.h H5CompType.h \ + H5DataSet.h H5DataSpace.h H5DataType.h H5OcreatProp.h H5DaccProp.h H5DcreatProp.h \ + H5DxferProp.h H5EnumType.h H5Exception.h H5FaccProp.h H5FcreatProp.h H5File.h \ + H5FloatType.h H5Group.h H5IdComponent.h H5Include.h H5IntType.h H5LcreatProp.h \ + H5LaccProp.h H5Library.h H5Location.h H5Object.h H5PredType.h H5PropList.h H5StrType.h \ + H5ArrayType.h H5VarLenType.h # The RECURSIVE tag can be used to specify whether or not subdirectories should # be searched for input files as well. @@ -908,7 +897,15 @@ EXCLUDE_SYMLINKS = NO # Note that the wildcards are matched against the file with absolute path, so to # exclude all test directories for example use the pattern */test/* -EXCLUDE_PATTERNS = +EXCLUDE_PATTERNS = */fortran/test/* +EXCLUDE_PATTERNS += */fortran/testpar/* +EXCLUDE_PATTERNS += */fortran/examples/* +EXCLUDE_PATTERNS += */fortran/src/*.c +EXCLUDE_PATTERNS += */fortran/src/*.h +EXCLUDE_PATTERNS += */hl/fortran/examples/* +EXCLUDE_PATTERNS += */hl/fortran/test/* +EXCLUDE_PATTERNS += */hl/fortran/src/*.c +EXCLUDE_PATTERNS += */hl/fortran/src/*.h # The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names # (namespaces, classes, functions, etc.) that should be excluded from the diff --git a/doxygen/dox/MetadataCachingInHDF5.dox b/doxygen/dox/MetadataCachingInHDF5.dox index b84ddea..ce7f0df 100644 --- a/doxygen/dox/MetadataCachingInHDF5.dox +++ b/doxygen/dox/MetadataCachingInHDF5.dox @@ -724,7 +724,7 @@ is allowed to write to file, and then only after entering a sync point with the other caches. After it writes entries to file, it sends the base addresses of the now clean entries to the other caches, so they can mark these entries clean as well, and then leaves the sync point. The other caches mark the specified -entries as clean before they leave the synch point as well. (Observe, that since +entries as clean before they leave the sync point as well. (Observe, that since all caches see the same stream of dirty metadata, they will all have the same set of dirty entries upon sync point entry and exit.) diff --git a/doxygen/dox/Overview.dox b/doxygen/dox/Overview.dox index 64e80c7..eaa942e 100644 --- a/doxygen/dox/Overview.dox +++ b/doxygen/dox/Overview.dox @@ -24,7 +24,7 @@ documents cover a mix of tasks, concepts, and reference, to help a specific Version-specific documentation (see the version in the title area) can be found here: - HDF5 1.12 branch (this site) - - HDF5 1.12.x + - HDF5 1.14.x - HDF5 1.10.x - HDF5 1.8.x diff --git a/doxygen/dox/PredefinedDatatypeTables.dox b/doxygen/dox/PredefinedDatatypeTables.dox new file mode 100644 index 0000000..fbafa94 --- /dev/null +++ b/doxygen/dox/PredefinedDatatypeTables.dox @@ -0,0 +1,22 @@ +/** \page predefined_datatypes_tables HDF5 Predefined Datatypes + * + * The following datatypes are predefined in HDF5. + * + * \snippet{doc} tables/predefinedDatatypes.dox predefined_ieee_datatypes_table + * + * \snippet{doc} tables/predefinedDatatypes.dox predefined_std_datatypes_table + * + * \snippet{doc} tables/predefinedDatatypes.dox predefined_unix_datatypes_table + * + * \snippet{doc} tables/predefinedDatatypes.dox predefined_string_datatypes_table + * + * \snippet{doc} tables/predefinedDatatypes.dox predefined_intel_datatypes_table + * + * \snippet{doc} tables/predefinedDatatypes.dox predefined_dec_datatypes_table + * + * \snippet{doc} tables/predefinedDatatypes.dox predefined_mips_datatypes_table + * + * \snippet{doc} tables/predefinedDatatypes.dox predefined_native_datatypes_table + * + * \snippet{doc} tables/predefinedDatatypes.dox predefined_c9x_datatypes_table + */ diff --git a/doxygen/dox/ReferenceManual.dox b/doxygen/dox/ReferenceManual.dox index 7900925..b9bcd49 100644 --- a/doxygen/dox/ReferenceManual.dox +++ b/doxygen/dox/ReferenceManual.dox @@ -8,49 +8,156 @@ The functions provided by the HDF5 API are grouped into the following - + + + + + + + + + - + - + - + - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
-\include{doc} core_menu.md +
Core Reference Manual Modules
ModuleLanguageDescription
Attributes (H5A)@ref H5A "C"@ref H5::Attribute "C++"@ref FH5A "Fortran"@ref JH5A "Java"HDF5 attribute is a small metadata object describing the nature and/or intended usage of a primary data object. +
Datasets (H5D)@ref H5D "C"@ref H5::DataSet "C++"@ref FH5D "Fortran"@ref JH5D "Java"Manage HDF5 datasets, including the transfer of data between memory and disk and the description of dataset properties. +
Dataspaces (H5S)@ref H5S "C"@ref H5::DataSpace "C++"@ref FH5S "Fortran"@ref JH5S "Java"HDF5 dataspaces describe the shape of datasets in memory or in HDF5 files.
- -\include{doc} high_level_menu.md +
Datatypes (H5T)@ref H5T "C"@ref H5::DataType "C++"@ref FH5T "Fortran"@ref JH5T "Java"HDF5 datatypes describe the element type of HDF5 datasets and attributes.
- -\include{doc} fortran_menu.md +
Error Handling (H5E)@ref H5E "C"@ref H5::Exception "C++"@ref FH5E "Fortran"@ref JH5E "Java"HDF5 library error reporting.
- -\include{doc} java_menu.md +
Event Set (H5ES)@ref H5ES "C""C++""Fortran""Java"HDF5 event set life cycle used with HDF5 VOL connectors that enable the asynchronous feature in HDF5.
Deprecated functionsFunctions with \ref ASYNC\ref api-compat-macrosFiles (H5F)@ref H5F "C"@ref H5::H5File "C++"@ref FH5F "Fortran"@ref JH5F "Java"Manage HDF5 files. +
Filters (H5Z)@ref H5Z "C""C++"@ref FH5Z "Fortran"@ref JH5Z "Java"Manage HDF5 user-defined filters +
Groups (H5G)@ref H5G "C"@ref H5::Group "C++"@ref FH5G "Fortran"@ref JH5G "Java"Manage HDF5 groups. +
Identifiers (H5I)@ref H5I "C"@ref H5::IdComponent "C++"@ref FH5I "Fortran"@ref JH5I "Java"Manage identifiers defined by the HDF5 library. +
Library General (%H5)@ref H5 "C"@ref H5::H5Library "C++"@ref FH5 "Fortran"@ref JH5 "Java"Manage the life cycle of HDF5 library instances. +
Links (H5L)@ref H5L "C""C++"@ref FH5L "Fortran"@ref JH5L "Java"Manage HDF5 links and link types. +
Objects (H5O)@ref H5O "C""C++"@ref FH5O "Fortran"@ref JH5O "Java"Manage HDF5 objects (groups, datasets, datatype objects). +
Property Lists (H5P)@ref H5P "C"@ref H5::PropList "C++"@ref FH5P "Fortran"@ref JH5P "Java"HDF5 property lists are the main vehicle to configure the behavior of HDF5 API functions. +
Dynamically-loaded Plugins (H5PL)@ref H5PL "C""C++""Fortran"@ref JH5PL "Java"Manage the loading behavior of HDF5 plugins. +
References (H5R)@ref H5R "C""C++"@ref FH5R "Fortran"@ref JH5R "Java"Manage HDF5 references (HDF5 objects, attributes, and selections on datasets a.k.a. dataset regions). +
VOL Connector (H5VL)@ref H5VL "C""C++"@ref FH5VL "Fortran"@ref JH5VL "Java"Manage HDF5 VOL connector plugins. +
- - -Mind the gap + + +Language + + + + + + + + + + + + + + + + + + + + + +
High-level Reference Manual Modules
ModuleDescription
HDF5 Lite APIs (H5LT,H5LD)@ref H5LT "C""C++"@ref FH5LT "Fortran""Java"Functions to simplify creating and manipulating datasets, attributes and other features. +
HDF5 Images API (H5IM)@ref H5IM "C""C++"@ref FH5IM "Fortran""Java"Creating and manipulating HDF5 datasets intended to be interpreted as images. +
HDF5 Table APIs (H5TB)@ref H5TB "C""C++"@ref FH5TB "Fortran""Java"Creating and manipulating HDF5 datasets intended to be interpreted as tables. +
HDF5 Packet Table APIs (H5PT)@ref H5PT "C""C++""Fortran""Java"Creating and manipulating HDF5 datasets to support append- and read-only operations on table data. +
HDF5 Dimension Scales APIs (H5DS)@ref H5DS "C""C++"@ref FH5DS "Fortran""Java"Creating and manipulating HDF5 datasets that are associated with the dimension of another HDF5 dataset. +
HDF5 Optimizations APIs (H5DO)@ref H5DO "C""C++""Fortran""Java"Bypassing default HDF5 behavior in order to optimize for specific use cases. +
Extensions (H5LR, H5LT)@ref H5LR "C""C++""Fortran""Java" +
+ + + + + + + + + + + + + + + + +
Additional Java Reference Manual Modules
@ref HDF5CONSTThis class contains C constants and enumerated types of HDF5 library. +
@ref HDFNATIVEThis class encapsulates native methods to deal with arrays of numbers, converting from numbers to bytes and bytes to numbers. +
@ref HDFARRAYThis is a class for handling multidimensional arrays for HDF. +
@ref ERRORSThe class HDF5Exception returns errors from the Java HDF5 Interface. +
+ + + + +\ref predefined_datatypes_tables
+Deprecated functions
+Functions with \ref ASYNC
+\ref api-compat-macros + + + + Follow these simple rules and stay out of trouble: -\li \Bold{Handle discipline:} The HDF5 C-API is rife with handles or +\li \Bold{Handle discipline:} The HDF5 API is rife with handles or identifiers, which you typically obtain by creating new HDF5 items, copying - items, or retrieving facets of items. \Emph{You acquire a handle, you own it!} - (Colin Powell) In other words, you are responsible for releasing the underlying + items, or retrieving facets of items. Consequently, \Bold{and most importantly}, you are + responsible for releasing the underlying resources via the matching \Code{H5*close()} call, or deal with the consequences of resource leakage. \li \Bold{Closed means closed:} Do not pass identifiers that were previously \Code{H5*close()}-d to other API functions! It will generate an error. \li \Bold{Dynamic memory allocation:} The API contains a few functions in which the HDF5 library dynamically allocates memory on the caller's behalf. The caller owns - this memory and eventually must free it by calling H5free_memory(). (\Bold{Not} - the `free` function \Emph{du jour}!) + this memory and eventually must free it by calling H5free_memory() and not language-explicit memory functions. \li \Bold{Be careful with that saw:} Do not modify the underlying collection when an iteration is in progress! \li \Bold{Use of locations:} Certain API functions, typically called \Code{H5***_by_name} @@ -58,7 +165,6 @@ Follow these simple rules and stay out of trouble: If the identifier fully specifies the object in question, pass \Code{'.'} (a dot) for the name! -Break a leg! diff --git a/doxygen/dox/ViewTools.dox b/doxygen/dox/ViewTools.dox index 0b685a0..2212d4b 100644 --- a/doxygen/dox/ViewTools.dox +++ b/doxygen/dox/ViewTools.dox @@ -829,6 +829,7 @@ by simply viewing the specified dataset with the -d option must be specified - -before -\par subsetting options (if not using the shorthand method). +Where, the -d option must be specified +before subsetting options (if not using the shorthand method). The -A 0 option suppresses the printing of attributes. diff --git a/doxygen/dox/cookbook/Accessibility.dox b/doxygen/dox/cookbook/Accessibility.dox index f100283..28009be 100644 --- a/doxygen/dox/cookbook/Accessibility.dox +++ b/doxygen/dox/cookbook/Accessibility.dox @@ -1,6 +1,6 @@ /** \page Accessibility -\section Accessibility +\section secAccessibility Accessibility \subsection CB_MaintainCompat Maintaining Compatibility with other HDF5 Library Versions diff --git a/doxygen/dox/cookbook/Attributes.dox b/doxygen/dox/cookbook/Attributes.dox index 68fd159..5914909 100644 --- a/doxygen/dox/cookbook/Attributes.dox +++ b/doxygen/dox/cookbook/Attributes.dox @@ -1,6 +1,6 @@ /** \page Attributes -\section Attributes +\section secAttributes Attributes \subsection CB_LargeAttributes Creating "Large" HDF5 Attributes diff --git a/doxygen/dox/cookbook/Files.dox b/doxygen/dox/cookbook/Files.dox index 169d638..4893771 100644 --- a/doxygen/dox/cookbook/Files.dox +++ b/doxygen/dox/cookbook/Files.dox @@ -1,6 +1,6 @@ /** \page Files -\section Files +\section secFiles Files \subsection CB_FreeSpace Tracking Free Space in HDF5 Files diff --git a/doxygen/dox/cookbook/Performance.dox b/doxygen/dox/cookbook/Performance.dox index 7ac3a18..5e945b2 100644 --- a/doxygen/dox/cookbook/Performance.dox +++ b/doxygen/dox/cookbook/Performance.dox @@ -1,6 +1,6 @@ /** \page Performance -\section Performance +\section secPerformance Performance \subsection CB_MDCPerf Assessing HDF5 Metadata Cache Performance diff --git a/doxygen/dox/high_level/extension.dox b/doxygen/dox/high_level/extension.dox index e8471b9..d754b96 100644 --- a/doxygen/dox/high_level/extension.dox +++ b/doxygen/dox/high_level/extension.dox @@ -8,13 +8,16 @@ * These functions were created as part of a project supporting * NPP/NPOESS Data Production and Exploitation ( * - * project, software). + * project, + * software ). * While they were written to facilitate access to NPP, NPOESS, and JPSS * data in the HDF5 format, these functions may be useful to anyone working * with region references, hyperslab selections, or bit-fields. * - * Note that these functions are not part of the standard HDF5 distribution; - * the software must be separately downloaded and installed. + * Note that these functions are not part of the standard HDF5 distribution; + * the + * software + * must be separately downloaded and installed. * * A comprehensive guide to this library, * @@ -28,7 +31,7 @@ * \n Copies data from a referenced region to a region in a destination dataset. * - \ref H5LRcreate_ref_to_all * \n Creates a dataset with the region references to the data in all datasets located under a - * specified group in a file or creates a dataset with object references to all objects (groups or datasets) + * specified group in a file or creates a dataset with object references to all objects (groups or datasets) * located under a specified group in a file. * - \ref H5LRcreate_region_references * \n Creates an array of region references using an array of paths to diff --git a/doxygen/examples/H5.format.2.0.html b/doxygen/examples/H5.format.2.0.html index 242fdea..d2979e1 100644 --- a/doxygen/examples/H5.format.2.0.html +++ b/doxygen/examples/H5.format.2.0.html @@ -1,289 +1,392 @@ - - - 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. 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. +
  +
    +
  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
- -
  • Disk Format: Level 2B - Data Object Data Storage
    • - - -
  • Appendix A: Definitions
    • -
  • Appendix B: File Memory Allocation Types
    • - -
    + + +
    @@ -293,14610 +396,14857 @@ div { page-break-inside:avoid;

    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.

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

    +

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

    +

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

    -
    -
    +

    + II. Disk Format: Level 0 - File Metadata +

    -
    -

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

    + II.A. Disk Format: Level 0A - Format + Signature and Superblock +

    - - - - -
      - (Items marked with an ‘O’ in the above table are - of the size specified in “Size of Offsets.”) -
    +

    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:

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

    + + + + + + + + + -
    -
    Superblock (Versions 0 and 1)
    bytebytebytebyte

    Format Signature (8 bytes)
    +
    - + + + + + + - - - - - + + + + + - - + + - + - + + - + -
    - Driver Information Block -
    Version # of SuperblockVersion # of File’s Free Space StorageVersion # of Root Group Symbol Table EntryReserved (zero)
    bytebytebytebyte
    Version # of Shared Header Message FormatSize of OffsetsSize of LengthsReserved (zero)
    VersionReservedGroup Leaf Node KGroup Internal Node K
    Driver Information SizeFile Consistency Flags

    Driver Identification (8 bytes)

    		Indexed Storage Internal + Node K1 + Reserved (zero)1


    Driver Information (variable size)



    Base AddressO
    +
    -
    -
    -
    - - - - + + - - + - - + - - + +
    Field NameDescription

    Address of File Free space InfoO
    +

    Version

    		 -

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

    -
    End of File AddressO
    +

    Driver Information Size

    		 -

    The size in bytes of the Driver Information field. -

    -
    Driver Information Block AddressO
    +

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

    -     		Root Group Symbol Table Entry
    - -

    Driver Information

    - Driver information is stored in a format defined by the - file driver (see description below). + + + + -
     (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) + + + -
    - 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

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

    + - -

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

    - - - - + +

    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)

    -
    - Family Driver Information -
    bytebytebytebyte

    Size of Member File

    -
    +

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

    + -
    -
    - - - - - - - - - - -
    Field NameDescription

    Size of Member File

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

    -
    + +

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

    -
    -

    -II.C. Disk Format: Level 0C - Superblock Extension

    +

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

    + + -

    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:

    - + +

    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.

    -
    -
    -
    -

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

    - -
    - - +

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

    + - - - - + + - + + - - - + + - + + - + + - + + - + + - + + - + + - + + +
    - B-link Tree Nodes -
    bytebytebytebyte

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

    Signature

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

    +
    Node TypeNode LevelEntries Used

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

    +

    Address of Left SiblingO

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

    +

    Address of Right SiblingO

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

    +
    Key 0 (variable size)

    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 Child 0O

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

    +
    Key 1 (variable size)

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

    +

    Address of Child 1O

    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)
    Key 2K (variable size)bytebytebytebyte

    Address of Child 2KO


    Format Signature (8 bytes)
    +
    Key 2K+1 (variable size)Version # of SuperblockSize of OffsetsSize of LengthsFile Consistency Flags
    - - - -
      - (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. -

    -
    Base AddressO
    +

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

    -

    Superblock Extension AddressO
    +

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

    -

    End of File AddressO
    +

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

    -

    Root Group Object Header AddressO
    +

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

    -
    Superblock Checksum
    - -

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

    - - + + + + +
     (Items marked with an ‘O’ in the + above table are of the size specified in “Size of + Offsets.”)
    - -

    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
    + Field Name + Description + - - - - - - -
      - (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.

    -

    Format Signature

    		 +

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

    +

    Node Size

    		 -

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

    -

    Version Number of the Superblock

    		 +

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

    +

    Record Size

    		 -

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

    -

    Size of Offsets

    		 +

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

    +

    Depth

    		 -

    This is the depth of the B-tree. -

    -

    Size of Lengths

    		 +

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

    +

    Split Percent

    		 -

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

    -

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

    +

    Merge Percent

    		 -

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

    -

    Base Address

    		 +

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

    +

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

    -

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

    +

    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

    End of File Address

    		 +

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

    +
    Signature

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

    +
    VersionTypeRecords 0, 1, 2...N-1 (variable size)

    Superblock Checksum

    		 +

    The checksum for the superblock.

    +

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

    + 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: +

    -
    -
    - - - - - - - - - +
    +
    Field NameDescription

    Signature

    		 -

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

    -
    + - - + + + + - - + + - - + - - + - - - - - - - - - - - - + +
    Driver Information Block

    Version

    		 -

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

    -     		bytebytebytebyte

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

    -     		VersionReserved

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

    -     		Driver Information Size

    Child Node Pointer

    		 -

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

    -
    Driver Identification (8 bytes)
    +

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

    -
    +
    Driver Information (variable size)
    +
    +
    +
    - - - -
    -
    -
    - - - +
    +
    +
    - Version 2 B-tree Leaf Node -
    - - - - + + - + + - - - - - - - - -
    bytebytebytebyteField NameDescription
    Signature

    Version

    		 +

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

    +
    VersionTypeRecord 0, 1, 2...N-1 (variable size)
    Checksum
    -
    -
    -
    - - - - + + + - - + + - - - + + + +
    Field NameDescription

    Driver Information Size

    		 +

    + The size in bytes of the Driver Information field. +

    +

    Signature

    		 -

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

    -

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

    +

    Version

    		 -

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

    -

    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: +

    - -

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

    - - +
    + + - - + + + + - - + + + + -
    Multi Driver Information

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

    -     		bytebytebytebyte

    Checksum

    		 -

    This is the checksum for this node. -

    -     		Member MappingMember MappingMember MappingMember Mapping
    -
    - -
    -

    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

    		Member MappingMember MappingReservedReserved
    - - - - - - -
      - (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 of Member File 1
    +

    Huge Object Address

    		 -

    The address of the huge object in the file. -

    -
    End of Address for Member File 1
    +

    Huge Object Length

    		 -

    The length of the huge object in the file. -

    -
    Address of Member File 2
    +

    Huge Object ID

    		 -

    The heap ID for the huge object. -

    -
    End of Address for Member File 2
    +
    -
    - -
    -
    -
    - - - - - - - + - + + - + + - + + - + + - + -
    - Version 2 B-tree, Type 2 Record Layout - Indirectly Accessed, Filtered, - ‘Huge’ Fractal Heap Objects -
    bytebytebytebyte
    ... ...
    +

    Filtered Huge Object AddressO


    Address of Member File N
    +

    Filtered Huge Object LengthL


    End of Address for Member File N
    +
    Filter Mask
    Name of Member File 1 (variable + size)
    +

    Filtered Huge Object Memory SizeL


    Name of Member File 2 (variable + size)
    +

    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.) -
    +
    Name of Member File N (variable + size)
    +
    + -
    + + -
    -
    - - - - +
    +
    +
    Field NameDescription
    + + + - - + + - - + + - - + + - - + + - - + + +
    Field NameDescription

    Filtered Huge Object Address

    		 -

    The address of the filtered huge object in the file. -

    -

    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.

    Filtered Huge Object Length

    		 -

    The length of the filtered huge object in the file. -

    -

    Reserved

    These fields are reserved and should always be zero.

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

    -

    Address of Member File N

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

    +

    N is the number of member files.

    Filtered Huge Object Memory Size

    		 -

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

    -

    End of Address for Member File N

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

    Huge Object ID

    		 -

    The heap ID for the huge object. -

    -

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

    +
    - - - -
    -
    -
    - - - - - - - - - +
    +
    +
    - Version 2 B-tree, Type 3 Record Layout - Directly Accessed, Non-Filtered, - ‘Huge’ Fractal Heap Objects -
    bytebytebytebyte
    + - - - - + + + + -
    Family Driver Information

    Huge Object AddressO


    Huge Object LengthL

    		bytebytebytebyte
    - - - - - - -
      - (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.) -
    +
    Size of Member File
    +
    + -
    + + -
    -
    - +
    +
    +
    - - + + - - + + +
    Field NameDescriptionField NameDescription

    Huge Object Address

    		 -

    The address of the huge object in the file. -

    -

    Size of Member File

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

    Huge Object Length

    - -

    The length of the huge object in the file. -

    - - +
    +

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

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

    +
    +

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

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

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

    -
    -
    - - - - - +
    +
    Field NameDescription
    + - - + + + + - - + - - + + + - - + -
    B-link Tree Nodes

    Filtered Huge Object Address

    		 -

    The address of the filtered huge object in the file. -

    -     		bytebytebytebyte

    Filtered Huge Object Length

    		 -

    The length of the filtered huge object in the file. -

    -     		Signature

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

    -     		Node TypeNode LevelEntries Used

    Filtered Huge Object Memory Size

    		 -

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

    -
    Address of Left SiblingO
    +
    -
    - -
    -
    -
    - - - - - - - - - - - + - - - - - - -
    - Version 2 B-tree, Type 5 Record Layout - Link Name for Indexed Group -
    bytebytebytebyte
    Hash of Name
    Address of Right SiblingO
    +
    ID (bytes 1-4)
    ID (bytes 5-7)
    -
    - -
    -
    - - - - + - - + - - + -
    Field NameDescriptionKey 0 (variable size)

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

    -
    Address of Child 0O
    +

    ID

    		 -

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

    -     		Key 1 (variable size)
    -
    - -
    -
    -
    - - - - - - - + - - - - + + - + -
    - Version 2 B-tree, Type 6 Record Layout - Creation Order for Indexed Group -
    bytebytebytebyte
    Address of Child 1O
    +

    Creation Order (8 bytes)

    ID (bytes 1-4)...
    ID (bytes 5-7)Key 2K (variable size) +
    -
    -
    -
    - - - + - - + +
    Field NameDescription
    Address of Child 2KO
    +

    Creation Order

    		 -

    This field is the creation order value for the link. -

    -     		Key 2K+1 (variable size) +
    + - - + + +

    ID

    		 -

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

    -     		 (Items marked with an ‘O’ in the + above table are of the size specified in “Size of + Offsets” field in the superblock.)
    - -
    - -
    -
    -
    - - + +
    +
    +
    - Version 2 B-tree, Type 7 Record Layout - Shared Object Header Messages (Sub-Type 0 - Message in Heap) -
    - - - - + + - - - - - - - - - - - + + -
    bytebytebytebyteField NameDescription
    Message LocationThis space inserted only to align table nicely
    Hash
    Reference Count

    Heap ID (8 bytes)

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

    +
    -
    -
    -
    - - - + + - - + + - - - + + + - - - + + + - - - + + + -
    Field NameDescription

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

    +

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

    -

    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.

    +

    Hash

    		 -

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

    -

    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.

    +

    Reference Count

    		 -

    The number of objects which reference this message.

    -

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

    +

    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.

    -

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

    + + -
    -
    -
    - - + + + - - - - - +

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

    +
    - Version 2 B-tree, Type 7 Record Layout - Shared Object Header Messages (Sub-Type 1 - Message in Object Header) -

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

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

    - - Message Location - This space inserted only to align table nicely - - - Hash + +

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

    + + - - Reserved (zero) - Message Type - Object Header Index + + +

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

    + - -
    Object Header AddressO

    + +
    + +

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

    - - - - -
      - (Items marked with an ‘O’ in the above table are of the size - specified in “Size of Offsets” field in the superblock.) -
    +

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

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

    -
    + - - - + + + + - - - - - - + - -
    Version 2 B-tree Header

    Message Type

    		 -

    The object header message type of the shared message.

    -
    bytebytebytebyte

    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.

    -     		Signature
    -
    - -
    -
    -
    - - - - - - - + + + - - + - - + + - + + + - + -
    - Version 2 B-tree, Type 8 Record Layout - Attribute Name for Indexed Attributes -
    bytebytebytebyteVersionTypeThis space inserted + only to align table nicely

    Heap ID (8 bytes)

    		Node Size
    Message FlagsThis space inserted only to align table nicelyRecord SizeDepth
    Creation OrderSplit PercentMerge PercentThis space inserted + only to align table nicely
    Hash of Name
    Root Node AddressO
    +
    -
    - -
    -
    - - - + + - - - + - - - + +
    Field NameDescriptionNumber of Records in Root NodeThis space inserted + only to align table nicely

    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.

    -
    Total Number of Records in B-treeL
    +

    Message Flags

    The object header message flags for the attribute message.

    -     		Checksum
    + - - + + - - - + + +

    Creation Order

    		 -

    This field is the creation order value for the attribute. -

    -     		 (Items marked with an ‘O’ in the + above table are of the size specified in “Size of + Offsets” field in the superblock.)

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

    -     		 (Items marked with an ‘L’ in the above table are + of the size specified in “Size of Lengths” field in the + superblock.)
    - -
    - -
    -
    -
    - - + +
    +
    +
    - Version 2 B-tree, Type 9 Record Layout- Creation Order for Indexed Attributes -
    - - - - + + - - - - - + + + - + + -
    bytebytebytebyteField NameDescription

    Heap ID (8 bytes)

    Message FlagsThis space inserted only to align table nicely

    Signature

    		 +

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

    +
    Creation Order

    Version

    		 +

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

    +
    -
    -
    -
    - - - + + - - - + + + - - - + + + - - - + + + -
    Field NameDescription

    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.

    +

    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.

    -

    Node Size

    		 +

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

    +

    Message Flags

    		 -

    The object header message flags for the attribute message.

    -

    Record Size

    		 +

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

    +

    Creation Order

    		 -

    This field is the creation order value for the attribute. -

    -

    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.

    + + -
    -

    -III.B. Disk Format: Level 1B - Group Symbol Table Nodes

    + +

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

    + + -

    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.

    + +

    Number of Records in Root Node

    + +

    This is the number of records in the root node.

    + + -

    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.

    + +

    Total Number of Records in B-tree

    + +

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

    + + -

    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.

    + +

    Checksum

    + +

    This is the checksum for the B-tree header.

    + + + + -
    - - +
    +
    +
    +
    - Symbol Table Node (A Leaf of a B-link tree) -
    + - - - - + + + + - + - - - - + + + - - + -
    Version 2 B-tree Internal Node
    bytebytebytebytebytebytebytebyte
    SignatureSignature
    Version NumberReserved (zero)Number of SymbolsVersionTypeRecords 0, 1, 2...N-1 (variable size)


    Group Entries



    Child Node Pointer 0O
    +
    -
    - -
    -
    - - - + - - - + - - - + - + + - - + - - - + -
    Field NameDescription
    Number of Records N0 for Child + Node 0 (variable size)

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

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

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

    -
    Child Node Pointer 1O
    +

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

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

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

    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
    Child Node Pointer NO
    +

    Link Name OffsetO


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

    Object Header AddressO


    Total Number of Records for Child Node N + (optional, variable size)
    Cache TypeChecksum
    + - + + +
    Reserved (zero) (Items marked with an ‘O’ in the + above table are of the size specified in “Size of + Offsets” field in the superblock.)
    +
    + +
    +
    + - + + -


    Scratch-pad Space (16 bytes)


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

    -

    Signature

    		 +

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

    +
    -
    - -
    -

    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

    Version

    		 +

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

    +

    Address of B-treeO

    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.

    +

    Address of Name HeapO

    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.

    +
    - - - -
      - (Items marked with an ‘O’ in the above table are of the size - specified in “Size of Offsets” field in the superblock.) -
    - -
    +

    Child Node Pointer

    + +

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

    + + -
    -
    - - - + + - - + + - - + + -
    Field NameDescription

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

    +

    Address of B-tree

    		 -

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

    -

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

    +

    Address of Name Heap

    		 -

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

    -

    Checksum

    		 +

    This is the checksum for this node.

    +
    -
    + + -
    -

    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 -
    + - - - - + + + + - + -
    Version 2 B-tree Leaf Node
    bytebytebytebytebytebytebytebyte
    Offset to Link ValueSignature
    -
    - -
    -
    - - - + + + - - - + -
    Field NameDescriptionVersionTypeRecord 0, 1, 2...N-1 (variable size)

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

    -     		Checksum
    -
    + +
    -

    -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 -
    - - - - + + - + + - - + + - + + - + + - + + -
    bytebytebytebyteField NameDescription
    Signature

    Signature

    		 +

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

    +
    VersionReserved (zero)

    Version

    		 +

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

    +

    Data Segment SizeL

    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.

    +

    Offset to Head of Free-listL

    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.

    +

    Address of Data SegmentO

    Checksum

    		 +

    This is the checksum for this node.

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

    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
    - - + + + + - - + - - - + - - - + +
    Field NameDescriptionbytebytebytebyte

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

    -
    Huge Object AddressO
    +

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

    -
    Huge Object LengthL
    +

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

    -
    Huge Object IDL
    +
    + - - + + - - - + + -

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

    -     		 (Items marked with an ‘O’ in the + above table are of the size specified in “Size of + Offsets” field in the superblock.)

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

    -     		 (Items marked with an ‘L’ in the above table are + of the size specified in “Size of Lengths” field in the + superblock.)
    -
    - -

    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 -
    +
    + +
    +
    + - - - - + + - + + - - + + - + + - - - +
    bytebytebytebyteField NameDescription
    Signature

    Huge Object Address

    		 +

    The address of the huge object in the file.

    +
    VersionReserved (zero)

    Huge Object Length

    		 +

    The length of the huge object in the file.

    +

    Collection SizeL

    Huge Object ID

    		 +

    The heap ID for the huge object.

    +

    Global Heap Object 1

    +
    - -
    Global Heap Object 2

    - +
    +
    +
    + + - + + + + - + - - + -
    Version 2 B-tree, Type 2 Record Layout - Indirectly + Accessed, Filtered, ‘Huge’ Fractal Heap Objects

    ...

    		bytebytebytebyte

    Global Heap Object N


    Filtered Huge Object AddressO
    +

    Global Heap Object 0 (free space)


    Filtered Huge Object LengthL
    +
    - - - - - -
      - (Items marked with an ‘L’ in the above table are of the size - specified in “Size of Lengths” field in the superblock.) -
    - -
    - -
    -
    - - - + - - - + - - - + +
    Field NameDescriptionFilter Mask

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

    -
    Filtered Huge Object Memory SizeL
    +

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

    -
    Huge Object IDL
    +
    + - - + + - - - + + +

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

    -     		 (Items marked with an ‘O’ in the + above table are of the size specified in “Size of + Offsets” field in the superblock.)

    Global Heap Object 1 through N

    		 -

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

    -     		 (Items marked with an ‘L’ in the above table are + of the size specified in “Size of Lengths” field in the + superblock.)
    + +
    +
    +
    + - - + + -

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

    -     		Field NameDescription
    -
    - -
    -
    -
    - - - - - - + + - - + + - + + - + + - + + -
    - Global Heap Object -
    bytebytebytebyte

    Filtered Huge Object Address

    		 +

    The address of the filtered huge object in the file.

    +
    Heap Object IndexReference Count

    Filtered Huge Object Length

    		 +

    The length of the filtered huge object in the file.

    +
    Reserved (zero)

    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.

    +

    Object SizeL

    Filtered Huge Object Memory Size

    		 +

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

    +

    Object Data

    Huge Object ID

    		 +

    The heap ID for the huge object.

    +
    - - - - -
      - (Items marked with an ‘L’ in the above table are of the size - specified in “Size of Lengths” field in the superblock.) -
    + +
    - +
    +
    +
    + + -
    -
    -
    Version 2 B-tree, Type 3 Record Layout - Directly + Accessed, Non-Filtered, ‘Huge’ Fractal Heap Objects
    - - + + + + - - + - - - + +
    Field NameDescriptionbytebytebytebyte

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

    -
    Huge Object AddressO
    +

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

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

    Reserved

    		 -

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

    -     		 (Items marked with an ‘L’ in the above table are + of the size specified in “Size of Lengths” field in the + superblock.)
    +
    + +
    +
    + - - + + - - + + -

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

    -     		Field NameDescription

    Object Data

    		 -

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

    -

    Huge Object Address

    		 +

    The address of the huge object in the file.

    +
    -
    + +

    Huge Object Length

    + +

    The length of the huge object in the file.

    + + -
    -

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

    + + -
    - - +
    +
    +
    +
    - Global Heap ID -
    + - - - - + + + + - + - - + -
    Version 2 B-tree, Type 4 Record Layout - Directly + Accessed, Filtered, ‘Huge’ Fractal Heap Objects
    bytebytebytebytebytebytebytebyte

    Collection AddressO


    Filtered Huge Object AddressO
    +
    Object Index
    Filtered 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.) -
    - -
    - -
    -
    - + + - - + +
    Filter Mask
    Field NameDescription
    Filtered Huge Object Memory SizeL
    +
    + - - + + - - - + + +

    Collection Address

    		 -

    This field is the address of the global heap collection - where the data object is stored. -

    -     		 (Items marked with an ‘O’ in the + above table are of the size specified in “Size of + Offsets” field in the superblock.)

    ID

    		 -

    This field is the index of the data object within the - global heap collection. -

    -     		 (Items marked with an ‘L’ in the above table are + of the size specified in “Size of Lengths” field in the + superblock.)
    - -
    - - -
    -

    -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 -
    - - - - + + - + + - - + + - - + + - - + + +
    bytebytebytebyteField NameDescription
    Signature

    Filtered Huge Object Address

    		 +

    The address of the filtered huge object in the file.

    +
    VersionThis space inserted only to align table nicely

    Filtered Huge Object Length

    		 +

    The length of the filtered huge object in the file.

    +
    Heap ID LengthI/O Filters’ Encoded Length

    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.

    +
    FlagsThis space inserted only to align table nicely

    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
    Maximum Size of Managed Objectsbytebytebytebyte

    Next Huge Object IDL

    		Hash of Name

    v2 B-tree Address of Huge ObjectsO

    		ID (bytes 1-4)

    Amount of Free Space in Managed BlocksL

    		ID (bytes 5-7)
    +
    + +
    +
    + - + + - + + - + + +

    Address of Managed Block Free Space ManagerO

    		Field NameDescription

    Amount of Managed Space in HeapL

    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.

    +

    Amount of Allocated Managed Space in HeapL

    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

    Offset of Direct Block Allocation Iterator in Managed SpaceL

    		bytebytebytebyte

    Number of Managed Objects in HeapL


    Creation Order (8 bytes)
    +

    Size of Huge Objects in HeapL

    		ID (bytes 1-4)

    Number of Huge Objects in HeapL

    		ID (bytes 5-7)
    +
    +
    +
    + - + + - + + - - + + +

    Size of Tiny Objects in HeapL

    		Field NameDescription

    Number of Tiny Objects in HeapL

    Creation Order

    		 +

    This field is the creation order value for the link.

    +
    Table WidthThis space inserted only to align table nicely

    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)

    Starting Block SizeL

    		bytebytebytebyte

    Maximum Direct Block SizeL

    		Message LocationThis space inserted + only to align table nicely
    Maximum Heap SizeStarting # of Rows in Root Indirect BlockHash

    Address of Root BlockO

    		Reference Count
    Current # of Rows in Root Indirect BlockThis space inserted only to align table nicely
    Heap ID (8 bytes)
    +
    +
    +
    +
    + - + + - + + - + + - + + -

    Size of Filtered Root Direct Block (optional)L

    		Field NameDescription
    I/O Filter Mask (optional)

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

    +
    I/O Filter Information (optional, variable size)

    Hash

    		 +

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

    +
    Checksum

    Reference Count

    		 +

    The number of objects which reference this message.

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

    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)
    - - + + + + - - + + - - - + - - - + + + - - - + +
    Field NameDescriptionbytebytebytebyte

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

    -     		Message LocationThis space inserted + only to align table nicely

    Version

    		 -

    This document describes version 0.

    -     		Hash

    Heap ID Length

    		 -

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

    -     		Reserved (zero)Message TypeObject Header Index

    I/O Filters’ Encoded Length

    		 -

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

    -
    Object Header AddressO
    +
    + - - - - - - - + + +

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

    -     		 (Items marked with an ‘O’ in the + above table are of the size specified in “Size of + Offsets” field in the superblock.)
    +
    + +
    +
    + - - + + - - + + - - + + - - + + - - + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + -

    Next Huge Object ID

    		 -

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

    -     		Field NameDescription

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

    -

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

    +

    Amount of Free Space in Managed Blocks

    		 -

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

    -

    Hash

    		 +

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

    +

    Address of Managed Block Free Space Manager

    		 -

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

    -

    Message Type

    		 +

    The object header message type of the shared message.

    +

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

    -

    Object Header Index

    		 +

    + This field indicates that the shared message is the nth + message of its type in the specified object header. +

    +

    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.

    -

    Object Header Address

    		 +

    The address of the object header containing the shared + message.

    +
    -
    + + -
    -
    -
    - - +
    +
    +
    +
    - Fractal Heap Direct Block -
    + - - - - + + + + - + - - - + + - - + - - + +
    Version 2 B-tree, Type 8 Record Layout - Attribute + Name for Indexed Attributes
    bytebytebytebytebytebytebytebyte
    Signature
    Heap ID (8 bytes)
    +
    VersionThis space inserted only to align table nicelyMessage FlagsThis space inserted + only to align table nicely

    Heap Header AddressO

    		Creation Order
    Block Offset (variable size)Hash of Name
    +
    +
    +
    + - + + - + + -
    Checksum (optional)Field NameDescription

    Object Data (variable size)

    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.

    +
    - - - - -
      - (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 Flags

    The object header message flags for the attribute + message.

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

    -

    Creation Order

    		 +

    This field is the creation order value for the attribute.

    +

    Version

    		 -

    This document describes version 0.

    -

    Hash

    		 +

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

    +

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

    -
    +
    + +
    +
    +
    + + - - + + + + - - + - - - + + - -
    Version 2 B-tree, Type 9 Record Layout- Creation + Order for Indexed Attributes

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

    -     		bytebytebytebyte

    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.

    -
    Heap ID (8 bytes)
    +

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

    -     		Message FlagsThis space inserted + only to align table nicely
    -
    - -
    -
    -
    - - - - - - - + +
    - Fractal Heap Indirect Block -
    bytebytebytebyteCreation Order
    +
    +
    +
    + - + + - - + + - + + - + + - - - - - - - - - +
    SignatureField NameDescription
    VersionThis space inserted only to align table nicely

    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.

    +

    Heap Header AddressO

    Message Flags

    		 +

    The object header message flags for the attribute message.

    +
    Block Offset (variable size)

    Creation Order

    		 +

    This field is the creation order value for the attribute.

    +

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

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

    - -
    Child Direct Block #K-1 AddressO

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

    - - - Filter Mask for Direct Block #K-1 (optional) - +
    + + - - + + + + + - - - - - - + + - - + + + + - + -
    Symbol Table Node (A Leaf of a B-link tree)

    Child Indirect Block #0 AddressO

    bytebytebytebyte

    Child Indirect Block #1 AddressO

    ...
    Signature

    Child Indirect Block #N-1 AddressO

    Version NumberReserved (zero)Number of Symbols
    Checksum
    +
    Group Entries
    +
    +
    + +
    - - - - +
    +
    +
      - (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 NameDescriptionField 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. -

    -

    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

    		 -

    This document describes version 0.

    -

    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)

    +

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

    -

    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.

    +

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

    -

    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

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

    -     		bytebytebytebyte

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

    -

    Link Name OffsetO
    +

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

    -
    Object Header AddressO
    +

    Checksum

    		 -

    This is the checksum for the indirect block.

    -     		Cache Type
    - -
    - -
    -

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

    -
    Reserved (zero)
    -
    + +
    +
    Scratch-pad Space (16 bytes)
    +
    +
    + + -

    The specific format for each type of heap ID is described below: -

    + + + + + +
     (Items marked with an ‘O’ in the + above table are of the size specified in “Size of + Offsets” field in the superblock.)
    -
    - - + +
    +
    +
    Fractal Heap ID for Tiny Objects (sub-type 1 - ‘Normal’) -
    - - - - - + + + - - + + - + + -
    bytebytebytebyte
    Field NameDescription
    Version, Type & LengthThis space inserted only to align table nicely

    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.

    +

    Data (variable size)

    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.

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

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

    + +
    Version, Type & LengthExtended LengthThis space inserted only to align table nicely

    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.

    +
    Data (variable size)

    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.

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

    -
    -
    +

    + 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: +

    -
    -
    -
    - - +
    +
    Fractal Heap ID for Huge Objects (sub-type 1 & 2): indirectly accessed, non-filtered/filtered -
    + - - - - + + + + - - + - + +
    Object Header Scratch-pad Format
    bytebytebytebytebytebytebytebyte
    Version & TypeThis space inserted only to align table nicely
    Address of B-treeO
    +

    v2 B-tree KeyL (variable size)


    Address of Name HeapO
    +
    - - - +
    - - -
      - (Items marked with an ‘L’ in the above table are of the size - specified in “Size of Lengths” field in the superblock.) -
    -
    +   + (Items marked with an ‘O’ in the + above table are of the size specified in “Size of + Offsets” field in the superblock.) + + -
    -
    - + + +
    +
    +
    - - + + - - + + - - + +
    Field NameDescriptionField 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 of B-tree

    		 +

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

    +

    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.

    +

    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: +

    + +
    +
    Fractal Heap ID for Huge Objects (sub-type 3): directly accessed, non-filtered -
    + - - - - + + + + - - + +
    Symbolic Link Scratch-pad Format
    bytebytebytebytebytebytebytebyte
    Version & TypeThis space inserted only to align table nicelyOffset to Link Value
    +
    +
    +
    + - + + - + + +

    Address O

    		Field NameDescription

    Length L

    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 +

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

    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
    - - + + + + - - + - - + + - - + -
    Field NameDescriptionbytebytebytebyte

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

    - -     		Signature

    Address

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

    -     		VersionReserved (zero)

    Length

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

    -
    Data Segment SizeL
    +
    -
    - -
    -
    -
    - - - - - - + - - + +
    Fractal Heap ID for Huge Objects (sub-type 4): directly accessed, filtered -
    bytebytebytebyte
    Offset to Head of Free-listL
    +
    Version & TypeThis space inserted only to align table nicely
    Address of Data SegmentO
    +
    + - + + - - + + +

    Address O

    		 (Items marked with an ‘O’ in the + above table are of the size specified in “Size of + Offsets” field in the superblock.)

    Length L

    		 (Items marked with an ‘L’ in the above table are + of the size specified in “Size of Lengths” field in the + superblock.)
    + +
    +
    +
    + - + + - + + -
    Filter MaskField NameDescription

    De-filtered Size L

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

    +
    - - - - + + - - - -
      - (Items marked with an ‘O’ in the above table are of the size - specified in “Size of Offsets” field in the superblock.) -

    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.

    +
     (Items marked with an ‘L’ in the above table are of the size - specified in “Size of Lengths” field in the superblock.) -
    -
    - -
    -
    - - - + + - - + + - - - - - - - - - - - - - - - - - - + + + +
    Field NameDescription

    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.

    +

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

    - -

    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

    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.

    -

    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.

    + +
    +
    Fractal Heap ID for Managed Objects -
    bytebytebytebyte
    + - - + + + + + - + - + + -
    A Global Heap Collection
    Version & TypeThis space inserted only to align table nicelybytebytebytebyte
    Offset (variable size)Signature
    Length (variable size)VersionReserved (zero)
    -
    -
    -
    - - - - - - - - - - - - - - - - - - - + + -
    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.


    Collection SizeL
    +
    -
    - -
    -

    -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
    Global Heap Object 1
    +
    Signature
    Global Heap Object 2
    +
    VersionClient IDThis space inserted only to align table nicely
    ...
    +

    Total Space TrackedL


    Global Heap Object N
    +

    Total Number of SectionsL


    Global Heap Object 0 (free space)
    +
    + - - - - - - + + + +

    Number of Serialized SectionsL


    Number of Un-Serialized SectionsL

     (Items marked with an ‘L’ in the + above table are of the size specified in “Size of + Lengths” field in the superblock.)
    - - Number of Section Classes - This space inserted only to align table nicely - +
    +
    +
    + - - + + - - - + + + - - + + + - + + - + + - - + + + +
    Shrink PercentExpand PercentField NameDescription
    Size of Address SpaceThis space inserted only to align table nicely

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

    +

    Maximum Section Size L

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

    +

    Address of Serialized Section ListO

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

    +

    Size of Serialized Section List UsedL

    + Global Heap Object 1 through N +

    		+

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

    +

    Allocated Size of Serialized Section ListL

    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.

    +
    +
    - - Checksum - - +
    +
    +
    + + -
    Global Heap Object
    - - - - - -
      - (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 NameDescriptionbytebytebytebyte

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

    -     		Heap Object IndexReference Count

    Version

    		 -

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

    -     		Reserved (zero)

    Client ID

    		 -

    This is the client ID for identifying the user of this - free-space manager: - - - - - - - - - - - - - - - - - - - -
    IDDescription
    0Fractal heap -
    1File -
    2+Reserved. -

    - -
    Object SizeL
    +

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

    -
    Object Data
    +
    + - - + + +

    Number of Section Classes

    		 -

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

    -     		 (Items marked with an ‘L’ in the + above table are of the size specified in “Size of + Lengths” field in the superblock.)
    - -

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

    -     		Field NameDescription

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

    -

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

    +

    Maximum Section Size

    		 -

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

    -

    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.

    +

    Address of Serialized Section List

    		 -

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

    -

    Reserved

    		 +

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

    +

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

    -

    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.

    +

    Allocated Size of Serialized Section List

    		 -

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

    -

    Object Data

    		 +

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

    +
    - -

    Checksum

    - -

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

    - - +
    - - +
    +

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

    -
    -

    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 -
    + - - - - + + + + - + - - + +
    Global Heap ID
    bytebytebytebytebytebytebytebyte
    Signature
    Collection AddressO
    +
    VersionThis space inserted only to align table nicelyObject Index
    + - + + +

    Free-space Manager Header AddressO

    		 (Items marked with an ‘O’ in the + above table are of the size specified in “Size of + Offsets” field in the superblock.)
    +
    + +
    +
    + - + + - - - - - - - - - - - + + + - - - + + + + - - - +
    Number of Section Records in Set #0 (variable size)Field NameDescription
    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

    Collection Address

    		 +

    This field is the address of the global heap collection where + the data object is stored.

    +
    Record Set #0 Section Record #0 Data (variable size)

    ID

    		 +

    This field is the index of the data object within the global + heap collection.

    +
    ...
    +
    - - Record Set #0 Section Record #K-1 Offset(variable size) - - - Record Set #0 Section Record #K-1 Type - This space inserted only to align table nicely - +
    +

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

    - - Record Set #0 Section Record #K-1 Data (variable size) - +

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

    - - Number of Section Records in Set #1 (variable size) - +

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

    - - Size of Free-space Section Described in Record Set #1 (variable size) - +

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

    - - Record Set #1 Section Record #0 Offset(variable size) - +

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

    - - Record Set #1 Section Record #0 Type - This space inserted only to align table nicely - +

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

    - - Record Set #1 Section Record #0 Data (variable size) - +

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

    - - Record Set #1 Section Record #K-1 Offset(variable size) - +
    + + - - - - + + + + + + - - - + + + - - - + + + + - - - + + + + - + + - - + + - - - + + + - - - - + + + - - - + + + - - - + + + - - - + + + - - - - + + + - - - + + + - - - -
    Fractal Heap Header
    Record Set #1 Section Record #K-1 TypeThis space inserted only to align table nicely
    bytebytebytebyte
    Record Set #1 Section Record #K-1 Data (variable size)
    Signature
    ...
    VersionThis space inserted + only to align table nicely
    ...
    Heap ID LengthI/O Filters’ Encoded Length
    Number of Section Records in Set #N-1 (variable size)FlagsThis space inserted + only to align table nicely
    Size of Free-space Section Described in Record Set #N-1 (variable size)
    Maximum Size of Managed Objects
    Record Set #N-1 Section Record #0 Offset(variable size)

    Next Huge Object IDL
    +
    Record Set #N-1 Section Record #0 TypeThis space inserted only to align table nicely

    v2 B-tree Address of Huge ObjectsO
    +
    Record Set #N-1 Section Record #0 Data (variable size)

    Amount of Free Space in Managed BlocksL
    +
    ...

    Address of Managed Block Free Space + ManagerO
    +
    Record Set #N-1 Section Record #K-1 Offset(variable size)

    Amount of Managed Space in HeapL
    +
    Record Set #N-1 Section Record #K-1 TypeThis space inserted only to align table nicely

    Amount of Allocated Managed Space in HeapL
    +
    Record Set #N-1 Section Record #K-1 Data (variable size)

    Offset of Direct Block Allocation + Iterator in Managed SpaceL
    +
    Checksum
    + +
    Number of Managed Objects in HeapL
    +
    + - - - -
      - (Items marked with an ‘O’ in the above table are of the size - specified in “Size of Offsets” field in the superblock.) -
    -
    +
    Size of Huge Objects in HeapL
    +
    + -
    -
    - - - - + + - - + - - + - - + + - - - + + -

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

    - - + + + - - + + -

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

    - + + - - + + -

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

    - + + - - + -
    Field NameDescription

    Number of Huge Objects in HeapL
    +

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

    -
    Size of Tiny Objects in HeapL
    +

    Version

    		 -

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

    -
    Number of Tiny Objects in HeapL
    +

    Free-space Manager Header Address

    		 -

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

    -     		Table WidthThis space inserted + only to align table nicely

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

    +

    Starting Block SizeL
    +

    Maximum Direct Block SizeL
    +

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

    +     		Maximum Heap SizeStarting # of Rows in Root Indirect Block

    Address of Root BlockO
    +

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

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

    Size of Filtered Root Direct Block (optional)L
    +

    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: +

    		I/O Filter Mask (optional)
    - - - - + + + - - - - - - - - -
    TypeDescription
    I/O Filter Information (optional, + variable size)
    0File’s section (a range of actual bytes in file) -
    1+Reserved. -

    + + Checksum + -

    The defined record types for a fractal heap client are: + - - - - - +
    TypeDescription
    + + + + + + + + +
     (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.)
    - - 0 - Fractal heap “single” section - - +

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

    + - - + + - - + + - - - + + - - - + + -
    1Fractal heap “first row” section - Bit(s)Description
    2Fractal heap “normal row” section - 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. +
    3Fractal heap “indirect” section - 1If set, the direct blocks in the heap are checksummed.
    4+Reserved. - 2-7Reserved

    +
    +

    - + -

    Record Set #N Section #K Data

    - -

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

    - +

    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.

    + -

    Checksum

    - -

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

    - +

    Next Huge Object ID

    + +

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

    + - -
    - -
    -

    - The section-type specific data for each free-space section record is - described below: -

    - -
    - - - - + + -
    - File’s Section Data Record -
    No additional record data stored

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

    +
    -
    - -
    -
    -
    - - - + + -
    - Fractal Heap “Single” Section Data Record -
    No additional record data stored

    Amount of Free Space in Managed Blocks

    		 +

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

    +
    -
    - -
    -
    -
    - - - + + -
    - Fractal Heap “First Row” Section Data Record -
    Same format as “indirect” section data

    Address of Managed Block Free Space Manager

    		 +

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

    +
    -
    - -
    -
    -
    - - - + + -
    - Fractal Heap “Normal Row” Section Data Record -
    No additional record data stored

    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.

    +
    -
    - -
    -
    -
    - - - - - - + + - + + - - + + - - + + -
    - Fractal Heap “Indirect” Section Data Record -
    bytebytebytebyte

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

    +
    Fractal Heap Indirect Block Offset (variable size)

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

    +
    Block Start RowBlock Start Column

    Number of Managed Objects in Heap

    		 +

    This is the number of managed objects in the heap.

    +
    Number of BlocksThis space inserted only to align table nicely

    Size of Huge Objects in Heap

    		 +

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

    +
    -
    -
    -
    - - - - + + + - - + + - - + + - - + + - - + + -
    Field NameDescription

    Number of Huge Objects in Heap

    		 +

    This is the number of huge objects in the heap.

    +

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

    -

    Size of Tiny Objects in Heap

    		 +

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

    +

    Block Start Row

    		 -

    This is the row that the empty blocks start in. -

    -

    Number of Tiny Objects in Heap

    		 +

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

    +

    Block Start Column

    		 -

    This is the column that the empty blocks start in. -

    -

    Table Width

    		 +

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

    +

    Number of Blocks

    		 -

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

    -

    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.

    +
    -
    - -
    -

    -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

    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.

    +
    Signature

    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.

    +
    Version for index #0Index Type for index #0Message Type Flags for index #0

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

    +
    Minimum Message Size for index #0

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

    +
    List Cutoff for index #0v2 B-tree Cutoff for index #0

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

    +
    Number of Messages for index #0This space inserted only to align table nicely

    Index AddressO for index #0


    Fractal Heap AddressO for index #0

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

    +
    Version for index #N-1Index Type for index #N-1Message Type Flags for index #N-1

    Checksum

    		 +

    This is the checksum for the header.

    +
    +
    + +
    +
    +
    + + + - + + + + - - + - - - - - - - - - - - - - - - -
    Fractal Heap Direct Block
    Minimum Message Size for index #N-1bytebytebytebyte
    List Cutoff for index #N-1v2 B-tree Cutoff for index #N-1Signature
    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
    + Version + This 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
    Heap Header AddressO
    +

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

    -     		Block Offset (variable size)

    Version for index #N

    		 -

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

    -     		Checksum (optional)

    Index Type for index #N

    		 -

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

    -
    Object Data (variable size)
    +

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

    + + + + + +
     (Items marked with an ‘O’ in the + above table are of the size specified in “Size of + Offsets” field in the superblock.)
    +
    -

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

    - - +
    +
    + + + + + - - + + - - - - - - - + + + - - + + - - + + - - + + - - + + -
    Field NameDescription

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

    -

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

    +

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

    -

    Version

    		 +

    This document describes version 0.

    +

    Number of Messages for index #N

    		 -

    The number of shared messages being tracked for the index. -

    -

    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.

    +

    Index Address for index #N

    		 -

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

    -

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

    +

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

    +

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

    +

    Checksum

    		 -

    This is the checksum for the table.

    -

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

    +
    -
    + + -
    -

    - 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 -
    + - - - - + + + + - + - + + - + - + - + - - + -
    Fractal Heap Indirect Block
    bytebytebytebytebytebytebytebyte
    SignatureSignature
    Shared Message Record #0VersionThis space inserted + only to align table nicely
    Shared Message Record #1
    Heap Header AddressO
    +
    ...Block Offset (variable size)
    Shared Message Record #N-1
    Child Direct Block #0 AddressO
    +
    Checksum
    Size of Filtered Direct Block #0 (optional) + L
    +
    -
    - -
    -
    - - - - + + - - + - - - + - - - + -
    Field NameDescription
    Filter Mask for Direct Block #0 (optional)

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

    -
    Child Direct Block #1 AddressO
    +

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

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

    Checksum

    		 -

    This is the checksum for the list. -

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

    - 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
    Child Direct Block #K-1 AddressO
    +
    Hash Value
    Size of Filtered Direct Block #K-1 (optional)L
    +
    Reference CountFilter Mask for Direct Block #K-1 (optional)

    Fractal Heap ID


    Child Indirect Block #0 AddressO
    +
    -
    -
    -
    - - - - + + - - + - - + - - + +
    Field NameDescription

    Child Indirect Block #1 AddressO
    +

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

    -
    Child Indirect Block #N-1 AddressO
    +

    Reference Count

    		 -

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

    -     		Checksum
    + - - + + -

    Fractal Heap ID

    		 -

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

    -     		 (Items marked with an ‘O’ in the + above table are of the size specified in “Size of + Offsets” field in the superblock.)
    -
    - -
    -
    -
    - - - - - - - + + +
    - Shared Message Record, for messages stored in an object header -
    bytebytebytebyte (Items marked with an ‘L’ in the above table are + of the size specified in “Size of Lengths” field in the + superblock.)
    + +
    +
    +
    + - - + + - + + - - - + + - + + -
    Message LocationThis space inserted only to align table nicelyField NameDescription
    Hash Value

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

    +
    ReservedMessage TypeCreation Index

    Version

    		 +

    This document describes version 0.

    +

    Object Header AddressO

    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.

    +
    - - - -
      - (Items marked with an ‘O’ in the above table are of the size - specified in “Size of Offsets” field in the superblock.) -
    - -
    - -
    -
    - - - - + + - - + + - - + + - - - + + - - + + - - + + -
    Field NameDescription

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

    +

    Message Location

    		 -

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

    -

    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.

    +

    Hash Value

    		 -

    This is the hash value for the message. -

    -

    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.

    +

    Message Type

    		 -

    This is the message type in the object header. -

    -

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

    +

    Creation Index

    		 -

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

    -

    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.

    +

    Object Header Address

    		 -

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

    -

    Checksum

    		 +

    This is the checksum for the indirect block.

    +
    -
    + +
    -
    -
    -

    -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

    -
    +

    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.

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

    -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
    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: +

    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:

    + +
    - - + + - - + + + - - + + + - - + + + - - + + -
    ValueDescriptionSub-typeDescription
    0The Size of Chunk #0 field is 1 byte. - 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.

    +
    1The Size of Chunk #0 field is 2 bytes. - 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.

    +
    2The Size of Chunk #0 field is 4 bytes. - 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.

    +
    3The Size of Chunk #0 field is 8 bytes. - 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.

    +

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

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

    -
    -
    +

    The specific format for each type of heap ID is described below: +

    -
    -
    -
    - - - - - - - - - - - - - - - - - - - -
    - Shared Message (Version 2) -
    bytebytebytebyte
    VersionTypeThis space inserted only to align table nicely

    AddressO

    +
    + + -
    Fractal Heap ID for Tiny Objects (sub-type 1 - + ‘Normal’)
    - - -
      - (Items marked with an ‘O’ in the above table are of the size - specified in “Size of Offsets” field in the superblock.) -
    -
    + byte + byte + byte + byte + -
    -
    - - - - - - - - - - - - - - - - - - - - -
    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.

    -
    + + Version, Type & Length + This space inserted + only to align table nicely + -
    -
    -
    - - - - - - - - - - - - - - - - - - - -
    - 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
    - + +
    Data (variable size) + + +

    -

    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)

    + Field Name + Description + - - - -
      - (Items marked with an ‘L’ in the above table are of the size - specified in “Size of Lengths” field in the superblock.) -
    -
    +

    Version, Type & Length

    + +

    This is a bit field with the following definition:

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

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

    + + + + - -
    -

    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)

    + -
    Fractal Heap ID for Tiny Objects (sub-type 2 - + ‘Extended’)
    - - - - -
      - (Items marked with an ‘O’ in the above table are of the size - specified in “Size of Offsets” field in the superblock.) -
    -
    + byte + byte + byte + byte + -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + -
    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.

    -
    Version, Type & LengthExtended LengthThis space inserted + only to align table nicely
    -
    + + Data (variable size) + + +
    -

    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
    - - - - - - - - + +
    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: +

    Version, Type & Length

    		 +

    This is a bit field with the following definition:

    - - + + - - - - - - + + - - + + - - + + -
    VersionDescriptionBitDescription
    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. - 6-7The current version of ID format. This document describes + version 0.
    2Used when an array datatype needs to be encoded. - 4-5The ID type. Tiny objects have a value of 2. +
    3Used when a VAX byte-ordered type needs to be - encoded. Packs various other datatype classes more - efficiently also. - 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. +

    +
    +

    -

    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

    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.

    +
    0Fixed-Point

    Data

    		 +

    This is the data for the object.

    +
    1Floating-Point
    +

    - - 2 - Time - - - 3 - String - +
    +
    +
    + + - - - - + + + + + + - - - - + + + + - - - - + + + + +
    Fractal Heap ID for Huge Objects (sub-type 1 & 2): + indirectly accessed, non-filtered/filtered
    4Bit field
    bytebytebytebyte
    5Opaque
    Version & TypeThis space inserted + only to align table nicely
    6Compound

    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:

    + - - + + - - + + - - - + + - - - + + -
    7ReferenceBitDescription
    8Enumerated6-7The current version of ID format. This document describes + version 0.
    9Variable-Length4-5The ID type. Huge objects have a value of 1. +
    10Array0-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. +

    + - -

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

    - - +
    +
    +
    + + - - - - + + + + + + -
    Fractal Heap ID for Huge Objects (sub-type 3): + directly accessed, non-filtered

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

    -
    bytebytebytebyte
    -
    + + Version & Type + This space inserted + only to align table nicely + + +
    Address O
    +
    + -
    -

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

    -
    + +
    Length L
    +
    + -
    -
    - - - - - - - - - - - - - - -
    - 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). -

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

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

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

    Version & Type

    		 +

    This is a bit field with the following definition:

    - - + + - - + + - - + + - - + + - - - - -
    ValueDescriptionBitDescription
    0No normalization - 6-7The current version of ID format. This document describes + version 0.
    1The most significant bit of the mantissa is always set - (except for 0.0). - 4-5The ID type. Huge objects have a value of 1. +
    2The most significant bit of the mantissa is not stored, - but is implied to be set. - 0-3Reserved.
    3Reserved. -

    +
    +

    + - + - -

    7

    -

    Reserved (zero).

    - + +

    Address

    +

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

    + + - -

    8-15

    -

    Sign Location. This is the bit position of the sign - bit. Bits are numbered with the least significant bit zero.

    - + +

    Length

    +

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

    + + +
    - -

    16-23

    -

    Reserved (zero).

    - +
    +
    +
    + + -
    Fractal Heap ID for Huge Objects (sub-type 4): + directly accessed, filtered
    -
    + + byte + byte + byte + byte + -
    -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - -
    - Floating-Point Property Description -
    ByteByteByteByte
    Bit OffsetBit Precision
    Exponent LocationExponent SizeMantissa LocationMantissa Size
    Exponent Bias
    -
    + + Version & Type + This space inserted + only to align table nicely + -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + -
    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. -

    -

    Address O
    +
    -
    + +
    Length L
    +
    + + + Filter Mask + -
    -

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

    -
    + +
    De-filtered Size L
    +
    + -
    -
    - - - - - - - - - - - -
    - Time Property Description -
    ByteByte
    Bit Precision
    -
    + -
    -
    - - - - - - - - - - +
    Field NameDescription

    Bit Precision

    		 -

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

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

    Class specific information for Strings (Class 3):

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

    -
    + +

    Version & Type

    + +

    This is a bit field with the following definition:

    + + + + + -
    -
    -
    BitDescription
    - - - - - - - - - - - - - -
    - Bit Field Property Description -
    ByteByteByteByte
    Bit OffsetBit Precision
    - + + 6-7 + The current version of ID format. This document describes + version 0. + + + 4-5 + The ID type. Huge objects have a value of 1. + + + + 0-3 + Reserved. + + +

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

    -
    -
    + + + +

    Address

    +

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

    + -
    -

    Class specific information for Opaque (Class 5):

    - -
    - - - - - - - - - - - - - - - - - -
    - Opaque Bit Field Description -
    BitsMeaning

    0-7

    Length of ASCII tag in bytes.

    8-23

    Reserved (zero).

    -
    + +

    Length

    +

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

    + -
    -
    - - - - - - - - - - - - - -
    - Opaque Property Description -
    ByteByteByteByte

    ASCII Tag
    -
    -
    + +

    Filter Mask

    +

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

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

    -
    -
    + +

    Filtered Size

    +

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

    + + + -
    -

    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.

    + + + +
    Fractal Heap ID for Managed Objects
    bytebytebytebyte
    Version & TypeThis space inserted + only to align table nicely
    Offset (variable size)
    Length (variable size)
    +
    +
    +
    + + + + + -
    -
    Field NameDescription
    - + + + + - - - + + + + - - - + + + + +
    - Compound Properties Description for Datatype Version 1 -

    Version & Type

    This is a bit field with the following definition:

    + + + + + - - - - - - + + + + + + + + + + + + +
    BitDescription
    ByteByteByteByte
    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.
    +


    Name

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

    Byte Offset of Member

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

    +
    - - Dimensionality - Reserved (zero) - +
    +

    + III.G. Disk Format: Level 1G - + Free-space Manager +

    - - Dimension Permutation - +

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

    - - Reserved (zero) - +

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

    - - Dimension #1 Size (required) - +

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

    - - Dimension #2 Size (required) - +
    + + - - - + + + + + + - - - + + + - - - + + + + + -
    Free-space Manager Header
    Dimension #3 Size (required)
    bytebytebytebyte
    Dimension #4 Size (required)
    Signature

    Member Type Message

    VersionClient IDThis space inserted + only to align table nicely
    -
    + +
    Total Space TrackedL
    +
    + -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + -
    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. -

    -

    Total Number of SectionsL
    +
    -
    + +
    Number of Serialized SectionsL
    +
    + -
    -
    -
    - - - - - - - - - - - - - - - - - - - - - + + + -
    - Compound Properties Description for Datatype Version 2 -
    ByteByteByteByte

    Name

    Byte Offset of Member

    Member Type Message


    Number of Un-Serialized SectionsL
    +
    -
    + + Number of Section Classes + This space inserted + only to align table nicely + -
    -
    - - - - - - - - - - - - - - - - - - - - + + + + -
    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. -

    -
    Shrink PercentExpand Percent
    -
    + + Size of Address Space + This space inserted + only to align table nicely + + +
    Maximum Section Size L
    +
    + -
    -
    -
    - - - - - - - - - - - - - - - - - - - - - + + + -
    - Compound Properties Description for Datatype Version 3 -
    ByteByteByteByte

    Name

    Byte Offset of Member (variable size)

    Member Type Message


    Address of Serialized Section ListO
    +
    -
    + +
    Size of Serialized Section List UsedL
    +
    + -
    -
    - - - - - - - - - - - - - - - - - - - - + + + -
    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.


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

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

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

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

    -
    + +

    Version

    + +

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

    + + -
    -
    -
    - - + + + - - + + - - - + + + + - - + + + -
    - Enumeration Property Description for Datatype Versions 1 & 2 -

    Client ID

    		 +

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

    + + + + + - - - - - - + + + + + + + + + + + + +
    IDDescription
    ByteByteByteByte
    0Fractal heap
    1File
    2+Reserved.
    +

    -

    Base Type


    Names

    Total Space Tracked

    		 +

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

    +

    Values

    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.

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

    -

    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.

    + + -
    -
    -
    - - + + + + - - - - - - + + + + - - - + + + + - - - + + + + - - + + + -
    - Enumeration Property Description for Datatype Version 3 -

    Expand Percent

    		 +

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

    +
    ByteByteByteByte

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

    +

    Base Type

    Maximum Section Size

    		 +

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

    +

    Names

    Address of Serialized Section List

    		 +

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

    +

    Values

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

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

    -

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

    -
    -

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

    -
    +
    + + -
    -
    -
    -
    Free-space Section List
    - + + + + + + - - - - + - + + -
    - Variable-Length Property Description -
    bytebytebytebyte
    ByteByteByteByteSignature

    Base Type

    		VersionThis space inserted + only to align table nicely
    -
    + +
    Free-space Manager Header AddressO
    +
    + -
    -
    - - - - - - - - - - + + + -
    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. -

    -
    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 Type + This space inserted + only to align table nicely + -
    -

    Class specific information for Array (Class 10):

    + + Record Set #0 Section Record #0 Data (variable + size) + -

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

    + + Record Set #0 Section Record #K-1 Offset(variable + size) + + + Record Set #0 Section Record #K-1 Type + This space inserted + only to align table nicely + -
    - - + + + - - - - + - - - - + + + - - - - - - - - - + + + - - - - - - - - - + + + + - + -
    - Array Property Description for Datatype Version 2 -
    Record Set #0 Section Record #K-1 Data (variable + size)
    ByteByteByteByteNumber of Section Records in Set #1 (variable + size)
    DimensionalityReserved (zero)
    Size of Free-space Section Described in Record + Set #1 (variable size) +
    Dimension #1 Size
    .
    .
    .
    Dimension #n Size
    Record Set #1 Section Record #0 Offset(variable + size)
    Permutation Index #1
    .
    .
    .
    Permutation Index #n
    Record Set #1 Section Record #0 TypeThis space inserted + only to align table nicely

    Base Type

    		Record Set #1 Section Record #0 Data (variable + size)
    -
    + + ... + -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - + + + -
    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. -

    -
    Record Set #1 Section Record #K-1 Offset(variable + size)
    -
    + + Record Set #1 Section Record #K-1 Type + This space inserted + only to align table nicely + -
    -
    - - + + + - - - - + - - - - + + + - - - - - - - - - + + + - + -
    - Array Property Description for Datatype Version 3 -
    Record Set #1 Section Record #K-1 Data (variable + size)
    ByteByteByteByte...
    DimensionalityThis space inserted only to align table nicely
    ...
    Dimension #1 Size
    .
    .
    .
    Dimension #n Size
    Number of Section Records in Set #N-1 (variable + size)

    Base Type

    		Size of Free-space Section Described in Record + Set #N-1 (variable size) +
    -
    + + Record Set #N-1 Section Record #0 Offset(variable + size) + -
    -
    - - - - - - - - - - - - - - - - - - - - + + + + -
    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. -

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

    IV.A.2.e. The Data Storage - -Fill Value (Old) Message

    + + Record Set #N-1 Section Record #K-1 Type + This space inserted + only to align table nicely + - -
    - - - - - - - - -
    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)

    -
    + + Record Set #N-1 Section Record #K-1 Data (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. -

    -
    -
    + + Checksum + + + + + + + +
     (Items marked with an ‘O’ in the + above table are of the size specified in “Size of + Offsets” field in the superblock.)
    +
    -

    IV.A.2.f. The Data Storage - -Fill Value Message

    +
    + + + + + - -
    -
    Field NameDescription
    - - - - - - - -
    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)

    -
    + +

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

    + + -
    -
    - - - - - - - - - - + + + + - - - + + + + + - +

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

    + + - - - - - - - - - - - - - - - - - - - -
    Field NameDescription

    Version

    		 -

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

    Version

    		 +

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

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

    -

    -

    Free-space Manager Header Address

    		 +

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

    +

    Space Allocation Time

    		 -

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

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

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

    +

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

    -

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

    -
    -
    + +

    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.

    -
    -
    - - - - - - - - - - - - - - - - - - - - - - - -
    - Fill Value Message - Version 3 -
    bytebytebytebyte
    VersionFlagsThis space inserted only to align table nicely
    Size (optional)

    Fill Value (optional, variable size)

    -
    +

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

    + + -
    -
    - - - - - - - - - + +
    Field NameDescription

    Version

    		 -

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

    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: + +

    - - + + - - - - - - + + - - + + - - - - -
    VersionDescriptionTypeDescription
    0Never used -
    1Initial version of this message. - 0File’s section (a range of actual bytes in file)
    2In this version, the Size and Fill Value fields are - only present if the Fill Value Defined field is set - to 1. - 1+Reserved.
    3This version packs the other fields in the message - more efficiently than version 2. -

    +
    +

    - - +

    + The defined record types for a fractal heap client are: - -

    Flags

    - -

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

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

    + +

    - - + + - -

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

    - - + +

    Record Set #N Section #K Data

    + +

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

    + + - -

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

    - - - -
    + +

    Checksum

    + +

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

    + + + +

    -

    IV.A.2.g. The Link Message

    +

    The section-type specific data for each free-space section record + is described below:

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

    -
    +
    + + -
    -
    -
    File’s Section Data Record
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + -
    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.
    -

    - -
    No additional record data stored
    -
    + +
    -

    IV.A.2.h. The Data Storage - -External Data Files Message

    +
    +
    + + - -
    -
    Fractal Heap “Single” Section Data + Record
    - - - - - - - -
    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...

    + + No additional record data stored + + +
    + +
    +
    +
    + + -
    Fractal Heap “First Row” Section Data + Record
    - - -
      - (Items marked with an ‘O’ in the above table are of the size - specified in “Size of Offsets” field in the superblock.) -
    + Same format as “indirect” + section data + + +
    -
    +
    +
    +
    + + -
    -
    -
    Fractal Heap “Normal Row” Section Data + Record
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    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.

    -
    -
    + + No additional record data stored + + + -
    -
    - - - - - - - - - - - - - - - - - - - - - -
    - External File List Slot -
    bytebytebytebyte

    Name Offset in Local HeapL


    Offset in External Data FileL


    Data Size in External FileL

    +
    +
    +
    + + -
    Fractal Heap “Indirect” Section Data + Record
    - - -
      - (Items marked with an ‘L’ in the above table are of the size - specified in “Size of Lengths” field in the superblock.) -
    + byte + byte + byte + byte + -
    + + Fractal Heap Indirect Block Offset (variable + size) + -
    -
    - - - - - - - - - - - - - - - - - - - - -
    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)

    + + Block Start Row + Block Start Column + - - - -
      - (Items marked with an ‘O’ in the above table are of the size - specified in “Size of Offsets” field in the superblock.) -
    + Number of Blocks + This space inserted + only to align table nicely + + +
    -
    +
    +
    + + + + + -
    -
    -
    Field NameDescription
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + - - - - -
    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.

    -

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

    +

    Compact Data

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

    -
    -
    + +

    Block Start Row

    + +

    This is the row that the empty blocks start in.

    + + -
    -

    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)

    -
    + +

    Block Start Column

    + +

    This is the column that the empty blocks start in.

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

    -
    + +

    Number of Blocks

    + +

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

    + + + + -
    -

    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)

    -
    +
    +

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

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

    -
    +

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

    -
    -

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

    - - -
    - - - - - - - - - - - - - - - - - -
    - Contiguous Storage Property Description -
    bytebytebytebyte

    AddressO


    SizeL

    +
    + + -
    Shared Object Header Message Table
    - - + + + + + + - - -
      - (Items marked with an ‘O’ in the above table are of the size - specified in “Size of Offsets” field in the superblock.) -
    bytebytebytebyte
      - (Items marked with an ‘L’ in the above table are of the size - specified in “Size of Lengths” field in the superblock.) -
    + Signature + -
    + + Version for index #0 + Index Type for index #0 + Message Type Flags for index #0 + -
    -
    - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    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. -

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

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

    - - -
    -
    + Symbol Table Message +
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    - 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
    + + byte + byte + byte + byte + - - - -
      - (Items marked with an ‘O’ in the above table are of the size - specified in “Size of Offsets” field in the superblock.) -
    +
    v1 B-tree AddressO
    +
    + -
    + +
    Local Heap AddressO
    +
    + + -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - -
    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. -

    -
    -
    + + + + + +
     (Items marked with an ‘O’ in the + above table are of the size specified in “Size of + Offsets” field in the superblock.)
    + +

    -

    IV.A.2.j. The Bogus 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: 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
    -
    + + 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. + + + + -
    -
    - - - - - - - - - - -
    Field NameDescription

    Bogus Value

    		 -

    This value should always be: 0xdeadbeef.

    -
    -
    +
    + + + + + + + + + + + + + + + + + + +
    Modification Time Message
    bytebytebytebyte
    VersionReserved (zero)
    Seconds After UNIX Epoch
    +

    -

    IV.A.2.k. The Group Info 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: 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
    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
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + -
    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.

    -
    bytebytebytebyte
    -
    -

    + + Version + Indexed Storage Internal Node K + This space inserted only to align + table nicely + + + + Group Internal Node K + Group Leaf Node K + + +
    -

    IV.A.2.l. The Data Storage - Filter -Pipeline 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: - 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)

    -
    + + Header Message Name: Driver Info + + + Header Message Type: 0x0014 + + + Length: Varies + + + Status: Optional; may not be repeated. + -
    -
    - - - - - - - - - - - - - - - - - - - - -
    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.

    -
    + + 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. + + + + -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    - Filter Description -
    bytebytebytebyte
    Filter Identification ValueName Length
    FlagsNumber Client Data Values

    Name (variable size, optional)


    Client Data (variable size, optional)

    Padding (variable size, optional)
    -
    +
    + + -
    -
    -
    Driver Info Message
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    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 - - Contributions 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.

    -
    + + byte + byte + byte + byte + -
    -
    - - - - - - - - - - - - - - - - - - - -
    - Filter Pipeline Message - Version 2 -
    bytebytebytebyte
    VersionNumber of FiltersThis space inserted only to align table nicely

    Filter Description List (variable size)

    -
    + + Version + This space inserted + only to align table nicely + + +
    Driver Identification + -
    -
    - - - - - - - - - - - - - - - - - - - - -
    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.

    -
    + + Driver Information Size + This space inserted + only to align table nicely + -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    - Filter Description -
    bytebytebytebyte
    Filter Identification ValueName Length (optional)
    FlagsNumber Client Data Values

    Name (variable size, optional)


    Client Data (variable size, optional)

    -
    + +
    +
    Driver Information (variable size)
    +
    +
    + -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    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 - - Contributions 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

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

    -
    + + 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. + + + + -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    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 Info Message
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    - Attribute Message (Version 2) -
    bytebytebytebyte
    VersionFlagsName Size
    Datatype SizeDataspace Size

    Name (variable size)


    Datatype (variable size)


    Dataspace (variable size)


    Data (variable size)

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

    -
    -
    + + Version + Flags + Maximum Creation Index (optional) + + +
    Fractal Heap AddressO
    +
    + + +
    Attribute Name v2 B-tree AddressO
    +
    + + +
    Attribute Creation Order v2 B-tree + AddressO (optional)
    +
    + -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    - 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: + + + + + +
     (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:

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

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

    + -
    -

    IV.A.2.n. The Object Comment -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.

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

    -
    + +

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

    + -
    -
    - - - - - - - - - - -
    Field NameDescription

    Name

    A null terminated ASCII character string.

    -
    + +

    -

    IV.A.2.o. The Object -Modification Time (Old) Message

    +

    + IV.A.2.w. The Object Reference Count + 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
    -
    + + 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. + + +
    + -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    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

    + + + + + + - -
    -
    Object Reference Count
    bytebytebytebyte
    - - - - - - - -
    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
    VersionThis space inserted + only to align table nicely
    + + Reference count + + +
    - +
    +
    +
    - - -
      - (Items marked with an ‘O’ in the above table are of the size - specified in “Size of Offsets” field in the superblock.) -
    + Field Name + Description + -
    + +

    Version

    +

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

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

    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.q. The Object Header -Continuation Message

    +

    + IV.A.2.x. The File Space Info 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 -
    bytebytebytebyteHeader Message Name: File Space Info

    OffsetO

    		Header Message Type: 0x0018

    LengthL

    		Length: Fixed
    - - - - + + - - -
      - (Items marked with an ‘O’ in the above table are of the size - specified in “Size of Offsets” field in the superblock.) -
    Status: Optional; may not be repeated.
      - (Items marked with an ‘L’ in the above table are of the size - specified in “Size of Lengths” field in the superblock.) -
    + 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
    - - + + + + - - + + + - - - + -
    Field NameDescriptionbytebytebytebyte

    Offset

    This value is the address in the file where the - header continuation block is located.

    		VersionStrategyThresholdL

    Length

    This value is the length in bytes of the header continuation - block in the file.

    		Super-block Free-space Manager AddressO
    -
    -
    - -

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

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

    IV.A.2.r. The Symbol Table -Message

    + + + + + + + + + +
     (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.)
    - -
    - - - - - - - - -
    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 -
    - - - - + + - + + - + + -
    bytebytebytebyteField NameDescription

    v1 B-tree AddressO

    Version

    This is the version number of this message. This + document describes version 0.

    Local Heap AddressO

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

    - - - -
      - (Items marked with an ‘O’ in the above table are of the size - specified in “Size of Offsets” field in the superblock.) -
    +

    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.

    + -
    -
    - - - + + - - + + - - + + -
    Field NameDescription

    Raw Data Free-space Manager Address

    This is the address of the free-space manager for + H5FD_MEM_DRAW allocation type.

    v1 B-tree Address

    This value is the address of the v1 B-tree containing the - symbol table entries for the group.

    Global Heap Free-space Manager Address

    This is the address of the free-space manager for + H5FD_MEM_GHEAP allocation type.

    Local Heap Address

    This value is the address of the local heap containing - the link names for the symbol table entries for the group.

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

    + IV.B. Disk Format: Level 2B - Data Object + Data Storage +

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

    -
    -
    +

    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.

    -
    -

    IV.A.2.u. The Driver Info -Message

    +

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

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

    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.

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

    + V. Appendix A: Definitions +

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

    +

    Definitions of various terms used in this document are included + in this section.

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

    -
    TermDefinition
    -
    + + Undefined Address + The undefined address for a + file is a file address with all bits set: in other words, 0xffff...ff. + + -
    -

    IV.A.2.w. The Object Reference -Count Message

    + + Unlimited Size + The unlimited size for a size is + a value with all bits set: in other words, 0xffff...ff. + + - -
    - - - - - - - - -
    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
    +
    +
    +

    + VI. Appendix B: File Memory Allocation Types +

    - +

    There are six basic types of file memory allocation as follows:

    +
    +
    - - - - - -
      - (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.) -
    - -
    + Basic Allocation Type + Description + -
    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    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. -

    -
    -
    -
    + + H5FD_MEM_SUPER + File memory allocated for Superblock. + + + H5FD_MEM_BTREE + File memory allocated for B-tree. + -
    -

    -IV.B. Disk Format: Level 2B - Data Object Data Storage

    + + H5FD_MEM_DRAW + File memory allocated for raw data. + -

    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.

    + + H5FD_MEM_GHEAP + File memory allocated for Global Heap. + -

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

    + + H5FD_MEM_LHEAP + File memory allocated for Local Heap. + -

    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.

    + + H5FD_MEM_OHDR + File 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:

    +
    + + + + + -
    -
    -
    -

    -V. Appendix A: Definitions

    + + + + -

    Definitions of various terms used in this document are included in -this section.

    + + + + -
    -
    Basic Allocation TypeMapping of Allocation Types to Basic Allocation Types
    H5FD_MEM_SUPERnone
    H5FD_MEM_BTREEH5FD_MEM_SOHM_INDEX
    - - - - + + + + - - - - + + + + - - - - + + + + + + + +
    TermDefinition
    H5FD_MEM_DRAWH5FD_MEM_FHEAP_HUGE_OBJ
    Undefined AddressThe undefined - address for a file is a file address with all bits - set: in other words, 0xffff...ff.
    H5FD_MEM_GHEAPnone
    Unlimited SizeThe unlimited size - for a size is a value with all bits set: in other words, - 0xffff...ff.
    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:

    +
    + + + + + -
    -
    -
    -

    -VI. Appendix B: File Memory Allocation Types

    + + + + -

    There are six basic types of file memory allocation as follows: -

    -
    -
    Allocation TypeDescription
    H5FD_MEM_FHEAP_HDRFile memory allocated for Fractal Heap Header.
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    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.
    -
    + + H5FD_MEM_FHEAP_DBLOCK + File memory allocated for Fractal Heap Direct + Blocks. + -

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

    + + H5FD_MEM_FHEAP_IBLOCK + File memory allocated for Fractal Heap Indirect + Blocks. + -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    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
    -
    + + H5FD_MEM_FHEAP_HUGE_OBJ + File memory allocated for huge objects in the fractal heap. + -

    Allocation types that are mapped to basic allocation types are described below: -

    + + H5FD_MEM_FSPACE_HDR + File memory allocated for Free-space Manager + Header. + -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    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.
    -
    - + + H5FD_MEM_FSPACE_SINFO + File memory allocated for Free-space Section List + of the free-space manager. + + + + H5FD_MEM_SOHM_TABLE + File memory allocated for Shared Object Header + Message Table. + + + H5FD_MEM_SOHM_INDEX + File memory allocated for Shared Message Record + List. + + + + + diff --git a/doxygen/examples/H5.format.html b/doxygen/examples/H5.format.html index 378f7a3..c52e8ea 100644 --- a/doxygen/examples/H5.format.html +++ b/doxygen/examples/H5.format.html @@ -170,17 +170,14 @@ @@ -14647,9 +14644,9 @@ Data Layout message. 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.

    + 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. @@ -19601,7 +19598,7 @@ disk address for the chunk.

    0 - If set, it a a regular hyperslab, otherwise, irregular. + If set, it is a regular hyperslab, otherwise, irregular. diff --git a/doxygen/examples/H5R_examples.c b/doxygen/examples/H5R_examples.c new file mode 100644 index 0000000..b40b992 --- /dev/null +++ b/doxygen/examples/H5R_examples.c @@ -0,0 +1,171 @@ +/* -*- c-file-style: "stroustrup" -*- */ + +#include "hdf5.h" + +#include +#include +#include + +int +main(void) +{ + int ret_val = EXIT_SUCCESS; + + //! + { + __label__ fail_file, fail_fspace, fail_dset, fail_sel, fail_aspace, fail_attr, fail_awrite; + hid_t file, fspace, dset, aspace, attr; + H5R_ref_t ref; + + if ((file = H5Fcreate("reference.h5", H5F_ACC_TRUNC, H5P_DEFAULT, H5P_DEFAULT)) == H5I_INVALID_HID) { + ret_val = EXIT_FAILURE; + goto fail_file; + } + // create a region reference which selects all elements of the dataset at "/data" + if ((fspace = H5Screate_simple(2, (hsize_t[]){10, 20}, NULL)) == H5I_INVALID_HID) { + ret_val = EXIT_FAILURE; + goto fail_fspace; + } + if ((dset = H5Dcreate(file, "data", H5T_STD_I32LE, fspace, H5P_DEFAULT, H5P_DEFAULT, H5P_DEFAULT)) == + H5I_INVALID_HID) { + ret_val = EXIT_FAILURE; + goto fail_dset; + } + if (H5Sselect_all(fspace) < 0 || H5Rcreate_region(file, "data", fspace, H5P_DEFAULT, &ref) < 0) { + ret_val = EXIT_FAILURE; + goto fail_sel; + } + // store the region reference in a scalar attribute of the root group called "region" + if ((aspace = H5Screate(H5S_SCALAR)) == H5I_INVALID_HID) { + ret_val = EXIT_FAILURE; + goto fail_aspace; + } + if ((attr = H5Acreate(file, "region", H5T_STD_REF, aspace, H5P_DEFAULT, H5P_DEFAULT)) == + H5I_INVALID_HID) { + ret_val = EXIT_FAILURE; + goto fail_attr; + } + if (H5Awrite(attr, H5T_STD_REF, &ref) < 0) { + ret_val = EXIT_FAILURE; + goto fail_awrite; + } + +fail_awrite: + H5Aclose(attr); +fail_attr: + H5Sclose(aspace); +fail_aspace: + H5Rdestroy(&ref); +fail_sel: + H5Dclose(dset); +fail_dset: + H5Sclose(fspace); +fail_fspace: + H5Fclose(file); +fail_file:; + } + //! + + //! + { + __label__ fail_file, fail_attr, fail_aread; + hid_t file, attr; + H5R_ref_t ref; + + if ((file = H5Fopen("reference.h5", H5F_ACC_RDONLY, H5P_DEFAULT)) == H5I_INVALID_HID) { + ret_val = EXIT_FAILURE; + goto fail_file; + } + + // read the dataset region reference from the attribute + if ((attr = H5Aopen(file, "region", H5P_DEFAULT)) == H5I_INVALID_HID) { + ret_val = EXIT_FAILURE; + goto fail_attr; + } + if (H5Aread(attr, H5T_STD_REF, &ref) < 0) { + ret_val = EXIT_FAILURE; + goto fail_aread; + } + assert(H5Rget_type(&ref) == H5R_DATASET_REGION2); + + // get an HDF5 path name for the dataset of the region reference + { + char buf[255]; + if (H5Rget_obj_name(&ref, H5P_DEFAULT, buf, 255) < 0) { + ret_val = EXIT_FAILURE; + } + printf("Object name: \"%s\"\n", buf); + } + + H5Rdestroy(&ref); +fail_aread: + H5Aclose(attr); +fail_attr: + H5Fclose(file); +fail_file:; + } + //! + + //! + { + __label__ fail_file, fail_attr, fail_ref; + hid_t file, attr; + H5R_ref_t ref; + + if ((file = H5Fopen("reference.h5", H5F_ACC_RDWR, H5P_DEFAULT)) == H5I_INVALID_HID) { + ret_val = EXIT_FAILURE; + goto fail_file; + } + + // H5T_STD_REF is a generic reference type + // we can "update" the attribute value to refer to the attribute itself + if ((attr = H5Aopen(file, "region", H5P_DEFAULT)) == H5I_INVALID_HID) { + ret_val = EXIT_FAILURE; + goto fail_attr; + } + if (H5Rcreate_attr(file, "data", "region", H5P_DEFAULT, &ref) < 0) { + ret_val = EXIT_FAILURE; + goto fail_ref; + } + + assert(H5Rget_type(&ref) == H5R_ATTR); + + if (H5Awrite(attr, H5T_STD_REF, &ref) < 0) { + ret_val = EXIT_FAILURE; + } + + H5Rdestroy(&ref); +fail_ref: + H5Aclose(attr); +fail_attr: + H5Fclose(file); +fail_file:; + } + //! + + //! + { + __label__ fail_file, fail_ref; + hid_t file; + H5R_ref_t ref; + + // create an HDF5 object reference to the root group + if ((file = H5Fopen("reference.h5", H5F_ACC_RDONLY, H5P_DEFAULT)) == H5I_INVALID_HID) { + ret_val = EXIT_FAILURE; + goto fail_file; + } + if (H5Rcreate_object(file, ".", H5P_DEFAULT, &ref) < 0) { + ret_val = EXIT_FAILURE; + goto fail_ref; + } + + // H5Rdestroy() releases all resources associated with an HDF5 reference + H5Rdestroy(&ref); +fail_ref: + H5Fclose(file); +fail_file:; + } + //! + + return ret_val; +} diff --git a/doxygen/examples/VFL.html b/doxygen/examples/VFL.html index 624d942..78d1632 100644 --- a/doxygen/examples/VFL.html +++ b/doxygen/examples/VFL.html @@ -10,17 +10,14 @@ diff --git a/doxygen/examples/core_menu.md b/doxygen/examples/core_menu.md deleted file mode 100644 index 8c82cc5..0000000 --- a/doxygen/examples/core_menu.md +++ /dev/null @@ -1,65 +0,0 @@ -Core Library - -- @ref H5A "Attributes (H5A)" -
    -HDF5 attribute is a small metadata object describing the nature and/or intended usage of a primary data object. - -- @ref H5D "Datasets (H5D)" -
    -Manage HDF5 datasets, including the transfer of data between memory and disk and the description of dataset properties. - -- @ref H5S "Dataspaces (H5S)" -
    -HDF5 dataspaces describe the shape of datasets in memory or in HDF5 files. - -- @ref H5T "Datatypes (H5T)" -
    -HDF5 datatypes describe the element type of HDF5 datasets and attributes. - -- @ref H5E "Error Handling (H5E)" -
    -HDF5 library error reporting. - -- @ref H5F "Files (H5F)" -
    -Manage HDF5 files. - -- @ref H5Z "Filters (H5Z)" -
    -Manage HDF5 user-defined filters - -- @ref H5G "Groups (H5G)" -
    -Manage HDF5 groups. - -- @ref H5I "Identifiers (H5I)" -
    -Manage identifiers defined by the HDF5 library. - -- @ref H5 "Library General (H5)" -
    -Manage the life cycle of HDF5 library instances. - -- @ref H5L "Links (H5L)" -
    -Manage HDF5 links and link types. - -- @ref H5O "Objects (H5O)" -
    -Manage HDF5 objects (groups, datasets, datatype objects). - -- @ref H5P "Property Lists (H5P)" -
    -HDF5 property lists are the main vehicle to configure the behavior of HDF5 API functions. - -- @ref H5PL "Dynamically-loaded Plugins (H5PL)" -
    -Manage the loading behavior of HDF5 plugins. - -- @ref H5R "References (H5R)" -
    -Manage HDF5 references (HDF5 objects, attributes, and selections on datasets a.k.a. dataset regions). - -- @ref H5VL "VOL Connector (H5VL)" -
    -Manage HDF5 VOL connector plugins. diff --git a/doxygen/examples/fortran_menu.md b/doxygen/examples/fortran_menu.md deleted file mode 100644 index 8ef4ead..0000000 --- a/doxygen/examples/fortran_menu.md +++ /dev/null @@ -1,73 +0,0 @@ -Fortran Library - -- @ref FH5A "Attributes (H5A)" -
    -HDF5 attribute is a small metadata object describing the nature and/or intended usage of a primary data object. - -- @ref FH5D "Datasets (H5D)" -
    -Manage HDF5 datasets, including the transfer of data between memory and disk and the description of dataset properties. - -- @ref FH5S "Dataspaces (H5S)" -
    -HDF5 dataspaces describe the shape of datasets in memory or in HDF5 files. - -- @ref FH5T "Datatypes (H5T)" -
    -HDF5 datatypes describe the element type of HDF5 datasets and attributes. - -- @ref FH5E "Error Handling (H5E)" -
    -HDF5 library error reporting. - -- @ref FH5F "Files (H5F)" -
    -Manage HDF5 files. - -- @ref FH5Z "Filters (H5Z)" -
    -Manage HDF5 user-defined filters - -- @ref FH5G "Groups (H5G)" -
    -Manage HDF5 groups. - -- @ref FH5I "Identifiers (H5I)" -
    -Manage identifiers defined by the HDF5 library. - -- @ref FH5 "Library General (H5)" -
    -Manage the life cycle of HDF5 library instances. - -- @ref FH5L "Links (H5L)" -
    -Manage HDF5 links and link types. - -- @ref FH5O "Objects (H5O)" -
    -Manage HDF5 objects (groups, datasets, datatype objects). - -- @ref FH5P "Property Lists (H5P)" -
    -HDF5 property lists are the main vehicle to configure the behavior of HDF5 API functions. - -- @ref FH5R "References (H5R)" -
    -Manage HDF5 references (HDF5 objects, attributes, and selections on datasets a.k.a. dataset regions). - -- @ref FH5LT "High Level Lite (H5LT)" -
    -Functions to simplify creating and manipulating datasets, attributes and other features - -- @ref FH5IM "High Level Image (H5IM)" -
    -Creating and manipulating HDF5 datasets intended to be interpreted as images - -- @ref FH5TB "High Level Table (H5TB)" -
    -Creating and manipulating HDF5 datasets intended to be interpreted as tables - -- @ref FH5DS "High Level Dimension Scale (H5DS)" -
    -Creating and manipulating HDF5 datasets that are associated with the dimension of another HDF5 dataset diff --git a/doxygen/examples/high_level_menu.md b/doxygen/examples/high_level_menu.md deleted file mode 100644 index d209bf4..0000000 --- a/doxygen/examples/high_level_menu.md +++ /dev/null @@ -1,30 +0,0 @@ -High-level library -
    -The high-level HDF5 library includes several sets of convenience and standard-use APIs to -facilitate common HDF5 operations. - -- @ref H5LT -
    -Functions to simplify creating and manipulating datasets, attributes and other features - -- @ref H5IM -
    -Creating and manipulating HDF5 datasets intended to be interpreted as images - -- @ref H5TB -
    -Creating and manipulating HDF5 datasets intended to be interpreted as tables - -- @ref H5PT -
    -Creating and manipulating HDF5 datasets to support append- and read-only operations on table data - -- @ref H5DS -
    -Creating and manipulating HDF5 datasets that are associated with the dimension of another HDF5 dataset - -- @ref H5DO -
    -Bypassing default HDF5 behavior in order to optimize for specific use cases - -- @ref H5LR "Extensions (H5LR, H5LT)" diff --git a/doxygen/examples/java_menu.md b/doxygen/examples/java_menu.md deleted file mode 100644 index 1236838..0000000 --- a/doxygen/examples/java_menu.md +++ /dev/null @@ -1,84 +0,0 @@ -Java Library - @ref HDF5LIB - -- @ref JH5 -
    -This package is the Java interface for the HDF5 library. - -- @ref JH5A -
    -This package is the Java interface for the HDF5 library attribute APIs. - -- @ref JH5D -
    -This package is the Java interface for the HDF5 library dataset APIs. - -- @ref JH5S -
    -This package is the Java interface for the HDF5 library dataspace APIs. - -- @ref JH5T -
    -This package is the Java interface for the HDF5 library datatype APIs. - -- @ref JH5E -
    -This package is the Java interface for the HDF5 library error APIs. - -- @ref JH5F -
    -This package is the Java interface for the HDF5 library file APIs. - -- @ref JH5Z -
    -This package is the Java interface for the HDF5 library filter APIs. - -- @ref JH5G -
    -This package is the Java interface for the HDF5 library group APIs. - -- @ref JH5I -
    -This package is the Java interface for the HDF5 library identifier APIs. - -- @ref JH5L -
    -This package is the Java interface for the HDF5 library links APIs. - -- @ref JH5O -
    -This package is the Java interface for the HDF5 library object APIs. - -- @ref JH5P -
    -This package is the Java interface for the HDF5 library property list APIs. - -- @ref JH5PL -
    -This package is the Java interface for the HDF5 library plugin APIs. - -- @ref JH5R -
    -This package is the Java interface for the HDF5 library reference APIs. - -- @ref JH5VL -
    -This package is the Java interface for the HDF5 library VOL connector APIs. - -- @ref HDF5CONST -
    -This class contains C constants and enumerated types of HDF5 library. - -- @ref HDFNATIVE -
    -This class encapsulates native methods to deal with arrays of numbers, - * converting from numbers to bytes and bytes to numbers. - -- @ref HDFARRAY -
    -This is a class for handling multidimensional arrays for HDF. - -- @ref ERRORS -
    -The class HDF5Exception returns errors from the Java HDF5 Interface. - \ No newline at end of file diff --git a/doxygen/examples/menus/core_menu.md b/doxygen/examples/menus/core_menu.md new file mode 100644 index 0000000..3fd7d11 --- /dev/null +++ b/doxygen/examples/menus/core_menu.md @@ -0,0 +1,69 @@ +Core Library + +- @ref H5A "Attributes (H5A)" +
    +HDF5 attribute is a small metadata object describing the nature and/or intended usage of a primary data object. + +- @ref H5D "Datasets (H5D)" +
    +Manage HDF5 datasets, including the transfer of data between memory and disk and the description of dataset properties. + +- @ref H5S "Dataspaces (H5S)" +
    +HDF5 dataspaces describe the shape of datasets in memory or in HDF5 files. + +- @ref H5T "Datatypes (H5T)" +
    +HDF5 datatypes describe the element type of HDF5 datasets and attributes. + +- @ref H5E "Error Handling (H5E)" +
    +HDF5 library error reporting. + +- @ref H5ES "Event Set (H5ES)" +
    +HDF5 event set life cycle used with HDF5 VOL connectors that enable the asynchronous feature in HDF5. + +- @ref H5F "Files (H5F)" +
    +Manage HDF5 files. + +- @ref H5Z "Filters (H5Z)" +
    +Manage HDF5 user-defined filters + +- @ref H5G "Groups (H5G)" +
    +Manage HDF5 groups. + +- @ref H5I "Identifiers (H5I)" +
    +Manage identifiers defined by the HDF5 library. + +- @ref H5 "Library General (H5)" +
    +Manage the life cycle of HDF5 library instances. + +- @ref H5L "Links (H5L)" +
    +Manage HDF5 links and link types. + +- @ref H5O "Objects (H5O)" +
    +Manage HDF5 objects (groups, datasets, datatype objects). + +- @ref H5P "Property Lists (H5P)" +
    +HDF5 property lists are the main vehicle to configure the behavior of HDF5 API functions. + +- @ref H5PL "Dynamically-loaded Plugins (H5PL)" +
    +Manage the loading behavior of HDF5 plugins. + +- @ref H5R "References (H5R)" +
    +Manage HDF5 references (HDF5 objects, attributes, and selections on datasets a.k.a. dataset regions). + +- @ref H5VL "VOL Connector (H5VL)" +
    +Manage HDF5 VOL connector plugins. diff --git a/doxygen/examples/menus/fortran_menu.md b/doxygen/examples/menus/fortran_menu.md new file mode 100644 index 0000000..8ef4ead --- /dev/null +++ b/doxygen/examples/menus/fortran_menu.md @@ -0,0 +1,73 @@ +Fortran Library + +- @ref FH5A "Attributes (H5A)" +
    +HDF5 attribute is a small metadata object describing the nature and/or intended usage of a primary data object. + +- @ref FH5D "Datasets (H5D)" +
    +Manage HDF5 datasets, including the transfer of data between memory and disk and the description of dataset properties. + +- @ref FH5S "Dataspaces (H5S)" +
    +HDF5 dataspaces describe the shape of datasets in memory or in HDF5 files. + +- @ref FH5T "Datatypes (H5T)" +
    +HDF5 datatypes describe the element type of HDF5 datasets and attributes. + +- @ref FH5E "Error Handling (H5E)" +
    +HDF5 library error reporting. + +- @ref FH5F "Files (H5F)" +
    +Manage HDF5 files. + +- @ref FH5Z "Filters (H5Z)" +
    +Manage HDF5 user-defined filters + +- @ref FH5G "Groups (H5G)" +
    +Manage HDF5 groups. + +- @ref FH5I "Identifiers (H5I)" +
    +Manage identifiers defined by the HDF5 library. + +- @ref FH5 "Library General (H5)" +
    +Manage the life cycle of HDF5 library instances. + +- @ref FH5L "Links (H5L)" +
    +Manage HDF5 links and link types. + +- @ref FH5O "Objects (H5O)" +
    +Manage HDF5 objects (groups, datasets, datatype objects). + +- @ref FH5P "Property Lists (H5P)" +
    +HDF5 property lists are the main vehicle to configure the behavior of HDF5 API functions. + +- @ref FH5R "References (H5R)" +
    +Manage HDF5 references (HDF5 objects, attributes, and selections on datasets a.k.a. dataset regions). + +- @ref FH5LT "High Level Lite (H5LT)" +
    +Functions to simplify creating and manipulating datasets, attributes and other features + +- @ref FH5IM "High Level Image (H5IM)" +
    +Creating and manipulating HDF5 datasets intended to be interpreted as images + +- @ref FH5TB "High Level Table (H5TB)" +
    +Creating and manipulating HDF5 datasets intended to be interpreted as tables + +- @ref FH5DS "High Level Dimension Scale (H5DS)" +
    +Creating and manipulating HDF5 datasets that are associated with the dimension of another HDF5 dataset diff --git a/doxygen/examples/menus/high_level_menu.md b/doxygen/examples/menus/high_level_menu.md new file mode 100644 index 0000000..d209bf4 --- /dev/null +++ b/doxygen/examples/menus/high_level_menu.md @@ -0,0 +1,30 @@ +High-level library +
    +The high-level HDF5 library includes several sets of convenience and standard-use APIs to +facilitate common HDF5 operations. + +- @ref H5LT +
    +Functions to simplify creating and manipulating datasets, attributes and other features + +- @ref H5IM +
    +Creating and manipulating HDF5 datasets intended to be interpreted as images + +- @ref H5TB +
    +Creating and manipulating HDF5 datasets intended to be interpreted as tables + +- @ref H5PT +
    +Creating and manipulating HDF5 datasets to support append- and read-only operations on table data + +- @ref H5DS +
    +Creating and manipulating HDF5 datasets that are associated with the dimension of another HDF5 dataset + +- @ref H5DO +
    +Bypassing default HDF5 behavior in order to optimize for specific use cases + +- @ref H5LR "Extensions (H5LR, H5LT)" diff --git a/doxygen/examples/menus/java_menu.md b/doxygen/examples/menus/java_menu.md new file mode 100644 index 0000000..1236838 --- /dev/null +++ b/doxygen/examples/menus/java_menu.md @@ -0,0 +1,84 @@ +Java Library + @ref HDF5LIB + +- @ref JH5 +
    +This package is the Java interface for the HDF5 library. + +- @ref JH5A +
    +This package is the Java interface for the HDF5 library attribute APIs. + +- @ref JH5D +
    +This package is the Java interface for the HDF5 library dataset APIs. + +- @ref JH5S +
    +This package is the Java interface for the HDF5 library dataspace APIs. + +- @ref JH5T +
    +This package is the Java interface for the HDF5 library datatype APIs. + +- @ref JH5E +
    +This package is the Java interface for the HDF5 library error APIs. + +- @ref JH5F +
    +This package is the Java interface for the HDF5 library file APIs. + +- @ref JH5Z +
    +This package is the Java interface for the HDF5 library filter APIs. + +- @ref JH5G +
    +This package is the Java interface for the HDF5 library group APIs. + +- @ref JH5I +
    +This package is the Java interface for the HDF5 library identifier APIs. + +- @ref JH5L +
    +This package is the Java interface for the HDF5 library links APIs. + +- @ref JH5O +
    +This package is the Java interface for the HDF5 library object APIs. + +- @ref JH5P +
    +This package is the Java interface for the HDF5 library property list APIs. + +- @ref JH5PL +
    +This package is the Java interface for the HDF5 library plugin APIs. + +- @ref JH5R +
    +This package is the Java interface for the HDF5 library reference APIs. + +- @ref JH5VL +
    +This package is the Java interface for the HDF5 library VOL connector APIs. + +- @ref HDF5CONST +
    +This class contains C constants and enumerated types of HDF5 library. + +- @ref HDFNATIVE +
    +This class encapsulates native methods to deal with arrays of numbers, + * converting from numbers to bytes and bytes to numbers. + +- @ref HDFARRAY +
    +This is a class for handling multidimensional arrays for HDF. + +- @ref ERRORS +
    +The class HDF5Exception returns errors from the Java HDF5 Interface. + \ No newline at end of file diff --git a/doxygen/examples/tables/fileDriverLists.dox b/doxygen/examples/tables/fileDriverLists.dox new file mode 100644 index 0000000..1aae3ce --- /dev/null +++ b/doxygen/examples/tables/fileDriverLists.dox @@ -0,0 +1,139 @@ +/** File Driver List + * +//! [file_driver_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    I/O file drivers
    File DriverDescription
    #H5FD_COREStore in memory (optional backing store to disk file).
    #H5FD_FAMILYStore in a set of files.
    #H5FD_LOGStore in logging file.
    #H5FD_MPIOStore using MPI/IO.
    #H5FD_MULTIStore in multiple files. There are several options to control layout.
    #H5FD_SEC2Serial I/O to file using Unix “section 2” functions.
    #H5FD_STDIOSerial I/O to file using Unix “stdio” functions.
    +//! [file_driver_table] + * + * +//! [supported_file_driver_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Supported file drivers
    Driver NameDriver IdentifierDescriptionRelated API
    POSIX#H5FD_SEC2This driver uses POSIX file-system functions like read and write to perform I/O to a single, +permanent file on local disk with no system buffering. This driver is POSIX-compliant and is +the default file driver for all systems.#H5Pset_fapl_sec2
    Direct#H5FD_DIRECTThis is the #H5FD_SEC2 driver except data is written to or read from the file +synchronously without being cached by the system.#H5Pset_fapl_direct
    Log#H5FD_LOGThis is the #H5FD_SEC2 driver with logging capabilities.#H5Pset_fapl_log
    Windows#H5FD_WINDOWSThis driver was modified in HDF5-1.8.8 to be a wrapper of the POSIX driver, +#H5FD_SEC2. This change should not affect user applications.#H5Pset_fapl_windows
    STDIO#H5FD_STDIOThis driver uses functions from the standard C stdio.h to perform I/O +to a single, permanent file on local disk with additional system buffering.#H5Pset_fapl_stdio
    Memory#H5FD_COREWith this driver, an application can work with a file in memory for faster reads and +writes. File contents are kept in memory until the file is closed. At closing, the memory +version of the file can be written back to disk or abandoned.#H5Pset_fapl_core
    Family#H5FD_FAMILYWith this driver, the HDF5 file’s address space is partitioned into pieces and sent to +separate storage files using an underlying driver of the user’s choice. This driver is for +systems that do not support files larger than 2 gigabytes.#H5Pset_fapl_family
    Multi#H5FD_MULTIWith this driver, data can be stored in multiple files according to the type of the data. +I/O might work better if data is stored in separate files based on the type of data. The Split +driver is a special case of this driver.#H5Pset_fapl_multi
    SplitH5FD_SPLITThis file driver splits a file into two parts. One part stores metadata, and the other part +stores raw data. This splitting a file into two parts is a limited case of the Multi driver.#H5Pset_fapl_split
    Parallel#H5FD_MPIOThis is the standard HDF5 file driver for parallel file systems. This driver uses the MPI +standard for both communication and file I/O.#H5Pset_fapl_mpio
    Parallel POSIXH5FD_MPIPOSIXThis driver is no longer available
    StreamH5FD_STREAMThis driver is no longer available.
    +//! [supported_file_driver_table] + * + */ diff --git a/doxygen/examples/tables/predefinedDatatypes.dox b/doxygen/examples/tables/predefinedDatatypes.dox new file mode 100644 index 0000000..2427d0c --- /dev/null +++ b/doxygen/examples/tables/predefinedDatatypes.dox @@ -0,0 +1,629 @@ +/** Predefined Datatypes List + * +//! [predefined_ieee_datatypes_table] + + + + + + + + + + + + + + + + + + + + + + +
    Predefined IEEE Floating Point Datatypes
    DatatypeDescription
    #H5T_IEEE_F32BE32-bit big-endian IEEE floating point
    #H5T_IEEE_F32LE32-bit little-endian IEEE floating point
    #H5T_IEEE_F64BE64-bit big-endian IEEE floating point
    #H5T_IEEE_F64LE64-bit little-endian IEEE floating point
    +//! [predefined_ieee_datatypes_table] + * + * +//! [predefined_std_datatypes_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Predefined Standard Datatypes
    DatatypeDescription
    #H5T_STD_I8BE8-bit big-endian signed integer (2's complement)
    #H5T_STD_I8LE8-bit little-endian signed integer (2's complement)
    #H5T_STD_I16BE16-bit big-endian signed integer (2's complement)
    #H5T_STD_I16LE16-bit little-endian signed integer (2's complement)
    #H5T_STD_I32BE32-bit big-endian signed integer (2's complement)
    #H5T_STD_I32LE32-bit little-endian signed integer (2's complement)
    #H5T_STD_I64BE64-bit big-endian signed integer (2's complement)
    #H5T_STD_I64LE64-bit little-endian signed integer (2's complement)
    #H5T_STD_U8BE8-bit big-endian unsigned integer
    #H5T_STD_U8LE8-bit little-endian unsigned integer
    #H5T_STD_U16BE16-bit big-endian unsigned integer
    #H5T_STD_U16LE16-bit little-endian unsigned integer
    #H5T_STD_U32BE32-bit big-endian unsigned integer
    #H5T_STD_U32LE32-bit little-endian unsigned integer
    #H5T_STD_U64BE64-bit big-endian unsigned integer
    #H5T_STD_U64LE64-bit little-endian unsigned integer
    #H5T_STD_B8BE8-bit big-endian bitfield
    #H5T_STD_B8LE8-bit little-endian bitfield
    #H5T_STD_B16BE16-bit big-endian bitfield
    #H5T_STD_B16LE16-bit little-endian bitfield
    #H5T_STD_B32BE32-bit big-endian bitfield
    #H5T_STD_B32LE32-bit little-endian bitfield
    #H5T_STD_B64BE64-bit big-endian bitfield
    #H5T_STD_B64LE64-bit little-endian bitfield
    #H5T_STD_REF_OBJObject reference
    #H5T_STD_REF_DSETREGDataset region reference
    #H5T_STD_REFGeneric reference
    +//! [predefined_std_datatypes_table] + * + * +//! [predefined_unix_datatypes_table] + + + + + + + + + + + + + + + + + + + + + + +
    Predefined UNIX-specific Datatypes
    DatatypeDescription
    #H5T_UNIX_D32BE32-bit big-endian
    #H5T_UNIX_D32LE32-bit little-endian
    #H5T_UNIX_D64BE64-bit big-endian
    #H5T_UNIX_D64LE64-bit little-endian
    +//! [predefined_unix_datatypes_table] + * + * +//! [predefined_string_datatypes_table] + + + + + + + + + + + + + + + +
    Predefined String Datatypes
    DatatypeDescription
    #H5T_C_S1String datatype in C (size defined in bytes rather than in bits)
    #H5T_FORTRAN_S1String datatype in Fortran (as defined for the HDF5 C library)
    +//! [predefined_string_datatypes_table] + * + * +//! [predefined_intel_datatypes_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Predefined Intel-specific Datatypes
    DatatypeDescription
    #H5T_INTEL_I88-bit little-endian signed integer (2's complement)
    #H5T_INTEL_I1616-bit little-endian signed integer (2's complement)
    #H5T_INTEL_I3232-bit little-endian signed integer (2's complement)
    #H5T_INTEL_I6464-bit little-endian signed integer (2's complement)
    #H5T_INTEL_U88-bit little-endian unsigned integer
    #H5T_INTEL_U1616-bit little-endian unsigned integer
    #H5T_INTEL_U3232-bit little-endian unsigned integer
    #H5T_INTEL_U6464-bit little-endian unsigned integer
    #H5T_INTEL_B88-bit little-endian bitfield
    #H5T_INTEL_B1616-bit little-endian bitfield
    #H5T_INTEL_B3232-bit little-endian bitfield
    #H5T_INTEL_B6464-bit little-endian bitfield
    #H5T_INTEL_F3232-bit little-endian IEEE floating point
    #H5T_INTEL_F6464-bit little-endian IEEE floating point
    +//! [predefined_intel_datatypes_table] + * + * +//! [predefined_dec_datatypes_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Predefined DEC Alpha-specific Datatypes
    DatatypeDescription
    #H5T_ALPHA_I88-bit little-endian signed integer (2's complement)
    #H5T_ALPHA_I1616-bit little-endian signed integer (2's complement)
    #H5T_ALPHA_I3232-bit little-endian signed integer (2's complement)
    #H5T_ALPHA_I6464-bit little-endian signed integer (2's complement)
    #H5T_ALPHA_U88-bit little-endian unsigned integer
    #H5T_ALPHA_U1616-bit little-endian unsigned integer
    #H5T_ALPHA_U3232-bit little-endian unsigned integer
    #H5T_ALPHA_U6464-bit little-endian unsigned integer
    #H5T_ALPHA_B88-bit little-endian bitfield
    #H5T_ALPHA_B1616-bit little-endian bitfield
    #H5T_ALPHA_B3232-bit little-endian bitfield
    #H5T_ALPHA_B6464-bit little-endian bitfield
    #H5T_ALPHA_F3232-bit little-endian IEEE floating point
    #H5T_ALPHA_F6464-bit little-endian IEEE floating point
    +//! [predefined_dec_datatypes_table] + * + * +//! [predefined_openvms_datatypes_table] + + + + + + + + + + + + + + +
    Predefined OpenVMS DEC Alpha-specific Datatypes
    DatatypeDescription
    #H5T_VAX_F3232-bit floating point (Corresponds to F_Floating type)
    #H5T_VAX_F6464-bit floating point (Corresponds to G_Floating type)
    +//! [predefined_openvms_datatypes_table] + * + * +//! [predefined_mips_datatypes_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Predefined MIPS-specific Datatypes
    DatatypeDescription
    #H5T_MIPS_I88-bit big-endian signed integer (2's complement)
    #H5T_MIPS_I1616-bit big-endian signed integer (2's complement)
    #H5T_MIPS_I3232-bit big-endian signed integer (2's complement)
    #H5T_MIPS_I6464-bit big-endian signed integer (2's complement)
    #H5T_MIPS_U88-bit big-endian unsigned integer
    #H5T_MIPS_U1616-bit big-endian unsigned integer
    #H5T_MIPS_U3232-bit big-endian unsigned integer
    #H5T_MIPS_U6464-bit big-endian unsigned integer
    #H5T_MIPS_B88-bit big-endian bitfield
    #H5T_MIPS_B1616-bit big-endian bitfield
    #H5T_MIPS_B3232-bit big-endian bitfield
    #H5T_MIPS_B6464-bit big-endian bitfield
    #H5T_MIPS_F3232-bit big-endian IEEE floating point
    #H5T_MIPS_F6464-bit big-endian IEEE floating point
    +//! [predefined_mips_datatypes_table] + * + * +//! [predefined_native_datatypes_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Predefined Native Datatypes
    DatatypeDescription
    #H5T_NATIVE_CHARC-style char
    #H5T_NATIVE_SCHARC-style signed char
    #H5T_NATIVE_UCHARC-style unsigned signed char
    #H5T_NATIVE_SHORTC-style short
    #H5T_NATIVE_USHORTC-style unsigned short
    #H5T_NATIVE_INTC-style int
    #H5T_NATIVE_UINTC-style unsigned int
    #H5T_NATIVE_LONGC-style long
    #H5T_NATIVE_ULONGC-style unsigned long
    #H5T_NATIVE_LLONGC-style long long
    #H5T_NATIVE_ULLONGC-style unsigned long long
    #H5T_NATIVE_FLOATC-style float
    #H5T_NATIVE_DOUBLEC-style double
    #H5T_NATIVE_LDOUBLEC-style long double
    #H5T_NATIVE_B88-bit bitfield based on native types
    #H5T_NATIVE_B1616-bit bitfield based on native types
    #H5T_NATIVE_B3232-bit bitfield based on native types
    #H5T_NATIVE_B6464-bit bitfield based on native types
    #H5T_NATIVE_OPAQUEopaque unit based on native types
    #H5T_NATIVE_HADDRaddress type based on native types
    #H5T_NATIVE_HSIZEsize type based on native types
    #H5T_NATIVE_HSSIZEsigned size type based on native types
    #H5T_NATIVE_HERRerror code type based on native types
    #H5T_NATIVE_HBOOLBoolean type based on native types
    +//! [predefined_native_datatypes_table] + * + * +//! [predefined_c9x_datatypes_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Predefined ANSI C9x-specific Native Integer Datatypes
    DatatypeDescription
    #H5T_NATIVE_INT88-bit signed integer (2's complement)
    #H5T_NATIVE_UINT88-bit unsigned integer
    #H5T_NATIVE_INT_LEAST88-bit signed integer (2's complement) with storage to use least amount of space
    #H5T_NATIVE_UINT_LEAST88-bit unsigned integer with storage to use least amount of space
    #H5T_NATIVE_INT_FAST88-bit signed integer (2's complement) with storage to maximize performance
    #H5T_NATIVE_UINT_FAST88-bit unsigned integer with storage to maximize performance
    #H5T_NATIVE_INT1616-bit signed integer (2's complement)
    #H5T_NATIVE_UINT1616-bit unsigned integer
    #H5T_NATIVE_INT_LEAST1616-bit signed integer (2's complement) with storage to use least amount of space
    #H5T_NATIVE_UINT_LEAST1616-bit unsigned integer with storage to use least amount of space
    #H5T_NATIVE_INT_FAST1616-bit signed integer (2's complement) with storage to maximize performance
    #H5T_NATIVE_UINT_FAST1616-bit unsigned integer with storage to maximize performance
    #H5T_NATIVE_INT3232-bit signed integer (2's complement)
    #H5T_NATIVE_UINT3232-bit unsigned integer
    #H5T_NATIVE_INT_LEAST3232-bit signed integer (2's complement) with storage to use least amount of space
    #H5T_NATIVE_UINT_LEAST3232-bit unsigned integer with storage to use least amount of space
    #H5T_NATIVE_INT_FAST3232-bit signed integer (2's complement) with storage to maximize performance
    #H5T_NATIVE_UINT_FAST3232-bit unsigned integer with storage to maximize performance
    #H5T_NATIVE_INT6464-bit signed integer (2's complement)
    #H5T_NATIVE_UINT6464-bit unsigned integer
    #H5T_NATIVE_INT_LEAST6464-bit signed integer (2's complement) with storage to use least amount of space
    #H5T_NATIVE_UINT_LEAST6464-bit unsigned integer with storage to use least amount of space
    #H5T_NATIVE_INT_FAST6464-bit signed integer (2's complement) with storage to maximize performance
    #H5T_NATIVE_UINT_FAST6464-bit unsigned integer with storage to maximize performance
    +//! [predefined_c9x_datatypes_table] + * + */ diff --git a/doxygen/examples/tables/propertyLists.dox b/doxygen/examples/tables/propertyLists.dox new file mode 100644 index 0000000..375fd50 --- /dev/null +++ b/doxygen/examples/tables/propertyLists.dox @@ -0,0 +1,955 @@ +/** Property List Tables + * +//! [plcr_table] + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Property list class root functions (H5P)
    FunctionPurpose
    #H5PcloseTerminates access to a property list.
    #H5PcopyCopies an existing property list to create a new property list.
    #H5PcreateCreates a new property list as an instance of a property list class.
    #H5Pencode/#H5PdecodeEncodes/ecodes property list into/from a binary object buffer.
    #H5Pget_classReturns the property list class identifier for a property list
    +//! [plcr_table] + * +//! [plcra_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Property list class root (Advanced) functions (H5P)
    FunctionPurpose
    #H5Pclose_classCloses an existing property list class.
    #H5Pcopy_propCopies a property from one list or class to another.
    #H5Pcreate_classCreates a new property list class.
    #H5PequalCompares two property lists or classes for equality.
    #H5PexistQueries whether a property name exists in a property list or class.
    #H5Pget_class_nameRetrieves the name of a class.
    #H5Pget_class_parentRetrieves the parent class of a property class.
    #H5Pget_npropsQueries the number of properties in a property list or class.
    #H5Pget_sizeQueries the size of a property value in bytes.
    #H5PinsertRegisters a temporary property with a property list.
    #H5Pisa_classDetermines whether a property list is a member of a class.
    #H5PiterateIterates over properties in a property class or list
    #H5Pregister/#H5PunregisterRegisters/removes a permanent property with/from a property list class
    #H5PremoveRemoves a property from a property list.
    #H5Pset/#H5PgetSets/queries a property list value
    +//! [plcra_table] + * +//! [fcpl_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    File creation property list functions (H5P)
    FunctionPurpose
    #H5Pset_userblock/#H5Pget_userblockSets/retrieves size of userblock.
    #H5Pset_sizes/#H5Pget_sizesSets/retrieves byte size of offsets and lengths used to address objects in HDF5 file.
    #H5Pset_sym_k/#H5Pget_sym_kSets/retrieves size of parameters used to control symbol table nodes.
    #H5Pset_istore_k/#H5Pget_istore_kSets/retrieves size of parameter used to control B-trees for indexing chunked datasets.
    #H5Pset_file_space_page_size/#H5Pget_file_space_page_sizeSets or retrieves the file space page size used in paged aggregation and paged buffering.
    #H5Pset_file_space_strategy/#H5Pget_file_space_strategySets or retrieves the file space handling strategy, the persisting free-space and the free-space section size.
    #H5Pset_shared_mesg_nindexes/#H5Pget_shared_mesg_nindexesSets or retrieves number of shared object header message indexes in file +creation property list.
    #H5Pset_shared_mesg_indexConfigures the specified shared object header message index.
    #H5Pget_shared_mesg_indexRetrieves the configuration settings for a shared message index.
    #H5Pset_shared_mesg_phase_change/#H5Pget_shared_mesg_phase_changeSets or retrieves shared object header message storage phase change thresholds.
    #H5Pget_version
    +//! [fcpl_table] + * +//! [fapl_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    File access property list functions (H5P)
    FunctionPurpose
    #H5Pset_alignment/#H5Pget_alignmentSets/retrieves alignment properties.
    #H5Pset_cache/#H5Pget_cacheSets/retrieves metadata cache and raw data chunk cache parameters.
    #H5Pset_core_write_tracking/#H5Pget_core_write_trackingSets/retrieves write tracking information for core driver.
    #H5Pset_elink_file_cache_size/#H5Pget_elink_file_cache_sizeSets/retrieves the size of the external link open file cache from the specified +file access property list.
    #H5Pset_evict_on_close/#H5Pget_evict_on_closeSet/get the file access property list setting that determines whether an HDF5 object will be evicted from the library's metadata cache when it is closed.
    #H5Pset_gc_references/#H5Pget_gc_referencesSets/retrieves garbage collecting references flag.
    #H5Pset_family_offsetSets offset property for low-level access to a file in a family of files.
    #H5Pget_family_offsetRetrieves a data offset from the file access property list.
    #H5Pset_fclose_degree/#H5Pget_fclose_degreeSets/retrieves file close degree property.
    #H5Pset_file_imageSets an initial file image in a memory buffer.
    #H5Pget_file_imageRetrieves a copy of the file image designated as the initial content and structure of a file.
    #H5Pset_file_image_callbacks/#H5Pget_file_image_callbacksSets/gets the callbacks for working with file images.
    #H5Pset_file_locking/#H5Pget_file_lockingSets/retrieves file locking property values.
    #H5Pset_meta_block_size/#H5Pget_meta_block_sizeSets the minimum metadata blocksize or retrieves the current metadata block size setting.
    #H5Pset_metadata_read_attempts/#H5Pget_metadata_read_attemptsSets/gets the number of read attempts from a file access property list.
    #H5Pset_mdc_config/#H5Pget_mdc_configSet/get the initial metadata cache configuration in the indicated file access property list.
    #H5Pset_mdc_image_config/#H5Pget_mdc_image_configSet/get the metadata cache image option for a file access property list.
    #H5Pset_mdc_log_options/#H5Pget_mdc_log_optionsSet/get the metadata cache logging options.
    #H5Pset_multi_type/#H5Pget_multi_typeSets/gets the type of data property for the MULTI driver.
    #H5Pset_object_flush_cb/#H5Pget_object_flush_cbSet/get the object flush property values from the file access property list.
    #H5Pset_page_buffer_size/#H5Pget_page_buffer_sizeSet/get the the maximum size for the page buffer.
    #H5Pset_sieve_buf_size/#H5Pget_sieve_buf_sizeSets/retrieves maximum size of data sieve buffer.
    #H5Pset_libver_boundsSets bounds on library versions, and indirectly format versions, to be used +when creating objects.
    #H5Pget_libver_boundsRetrieves library version bounds settings that indirectly control the format +versions used when creating objects.
    #H5Pset_small_data_block_sizeSets the size of a contiguous block reserved for small data.
    #H5Pget_small_data_block_sizeRetrieves the current small data block size setting.
    #H5Pset_volSets the file VOL connector for a file access property list.
    #H5Pget_vol_cap_flagsRetrieves the capability flags for the VOL connector that will be used with a file access property list.
    #H5Pget_vol_idRetrieves the identifier of the current VOL connector.
    #H5Pget_vol_infoRetrieves a copy of the VOL information for a connector.
    #H5Pset_mpi_params/#H5Pget_mpi_paramsSets/retrieves the MPI communicator and info.
    #H5Pset_coll_metadata_write/#H5Pget_coll_metadata_writeSets/retrieves metadata write mode setting.
    +//! [fapl_table] + * +//! [fd_pl_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    File driver property list functions (H5P)
    FunctionPurpose
    #H5Pset_driverSets a file driver.
    #H5Pget_driverReturns the identifier for the driver used to create a file.
    #H5Pget_driver_infoReturns a pointer to file driver information.
    #H5Pset_driver_by_nameSets a file driver according to a given driver name.
    #H5Pset_driver_by_valueSets a file driver according to a given driver value.
    #H5Pget_driver_config_strRetrieves a string representation of the configuration for the driver.
    #H5Pset_fapl_core/#H5Pget_fapl_coreSets the driver for buffered memory files (in RAM) or retrieves information regarding +the driver.
    #H5Pset_fapl_direct/#H5Pget_fapl_directSets up use of the direct I/O driver or retrieves the direct I/O driver settings.
    #H5Pset_fapl_family/#H5Pget_fapl_familySets driver for file families, designed for systems that do not support files +larger than 2 gigabytes, or retrieves information regarding driver.
    #H5Pset_fapl_hdfs/#H5Pget_fapl_hdfs.
    #H5Pset_fapl_ioc/#H5Pget_fapl_iocModifies/queries the file driver properties of the I/O concentrator driver.
    #H5Pset_fapl_logSets logging driver.
    #H5Pset_fapl_mirror/#H5Pget_fapl_mirrorModifies/queries the file driver properties of the mirror driver.
    #H5Pset_fapl_mpio/#H5Pget_fapl_mpioSets driver for files on parallel file systems (MPI I/O) or retrieves information +regarding the driver.
    H5Pset_fapl_mpiposix/H5Pget_fapl_mpiposixNo longer available.
    #H5Pset_fapl_multi/#H5Pget_fapl_multiSets driver for multiple files, separating categories of metadata and raw data, +or retrieves information regarding driver.
    #H5Pset_fapl_onion/#H5Pget_fapl_onionModifies/queries the file driver properties of the onion driver.
    #H5Pset_fapl_sec2Sets driver for unbuffered permanent files or retrieves information regarding driver.
    #H5Pset_fapl_splitSets driver for split files, a limited case of multiple files with one metadata file +and one raw data file.
    #H5Pset_fapl_stdioSets driver for buffered permanent files.
    #H5Pset_fapl_subfiling/#H5Pget_fapl_subfilingModifies/queries the file driver properties of the subfiling driver.
    #H5Pset_fapl_windowsSets the Windows I/O driver.
    #H5Pset_multi_typeSpecifies type of data to be accessed via the MULTI driver enabling more direct access.
    #H5Pget_multi_typeRetrieves type of data property for MULTI driver.
    +//! [fd_pl_table] + * +//! [dcpl_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Dataset creation property list functions (H5P)
    FunctionPurpose
    #H5Pset_layoutSets the type of storage used to store the raw data for a dataset.
    #H5Pget_layoutReturns the layout of the raw data for a dataset.
    #H5Pset_chunkSets the size of the chunks used to store a chunked layout dataset.
    #H5Pget_chunkRetrieves the size of chunks for the raw data of a chunked layout dataset.
    #H5Pset_chunk_opts/#H5Pget_chunk_optsSets/gets the edge chunk option setting from a dataset creation property list.
    #H5Pset_deflateSets compression method and compression level.
    #H5Pset_fill_valueSets the fill value for a dataset.
    #H5Pget_fill_valueRetrieves a dataset fill value.
    #H5Pfill_value_definedDetermines whether the fill value is defined.
    #H5Pset_fill_timeSets the time when fill values are written to a dataset.
    #H5Pget_fill_timeRetrieves the time when fill value are written to a dataset.
    #H5Pset_alloc_timeSets the timing for storage space allocation.
    #H5Pget_alloc_timeRetrieves the timing for storage space allocation.
    #H5Pset_filterAdds a filter to the filter pipeline.
    #H5Pall_filters_availVerifies that all required filters are available.
    #H5Pget_nfiltersReturns the number of filters in the pipeline.
    #H5Pget_filterReturns information about a filter in a pipeline. +The C function is a macro: \see \ref api-compat-macros.
    #H5Pget_filter_by_idReturns information about the specified filter. +The C function is a macro: \see \ref api-compat-macros.
    #H5Pmodify_filterModifies a filter in the filter pipeline.
    #H5Premove_filterDeletes one or more filters in the filter pipeline.
    #H5Pset_fletcher32Sets up use of the Fletcher32 checksum filter.
    #H5Pset_nbitSets up use of the n-bit filter.
    #H5Pset_scaleoffsetSets up use of the scale-offset filter.
    #H5Pset_shuffleSets up use of the shuffle filter.
    #H5Pset_szipSets up use of the Szip compression filter.
    #H5Pset_externalAdds an external file to the list of external files.
    #H5Pget_external_countReturns the number of external files for a dataset.
    #H5Pget_externalReturns information about an external file.
    #H5Pset_char_encodingSets the character encoding used to encode a string. Use to set ASCII or UTF-8 character +encoding for object names.
    #H5Pget_char_encodingRetrieves the character encoding used to create a string.
    #H5Pset_virtualSets the mapping between virtual and source datasets.
    #H5Pget_virtual_countGets the number of mappings for the virtual dataset.
    #H5Pget_virtual_dsetnameGets the name of a source dataset used in the mapping.
    #H5Pget_virtual_filenameGets the filename of a source dataset used in the mapping.
    #H5Pget_virtual_srcspaceGets a dataspace identifier for the selection within the source dataset used in the mapping.
    #H5Pget_virtual_vspaceGets a dataspace identifier for the selection within the virtual dataset used in the mapping.
    #H5Pset_dset_no_attrs_hint/#H5Pget_dset_no_attrs_hintSets/gets the flag to create minimized dataset object headers.
    +//! [dcpl_table] + * +//! [dapl_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Dataset access property list functions (H5P)
    FunctionPurpose
    #H5Pset_bufferSets type conversion and background buffers.
    #H5Pget_bufferReads buffer settings.
    #H5Pset_append_flush/#H5Pget_append_flushSets/gets the values of the append property that is set up in the dataset access property list.
    #H5Pset_chunk_cache/#H5Pget_chunk_cacheSets/gets the raw data chunk cache parameters.
    #H5Pset_efile_prefix/#H5Pget_efile_prefixSets/gets the prefix for external raw data storage files as set in the dataset access property list.
    #H5Pset_virtual_prefix/#H5Pget_virtual_prefixSets/gets the prefix to be applied to VDS source file paths.
    #H5Pset_virtual_printf_gap/#H5Pget_virtual_printf_gapSets/gets the maximum number of missing source files and/or datasets with the printf-style names when getting the extent for an unlimited virtual dataset.
    #H5Pset_virtual_view/#H5Pget_virtual_viewSets/gets the view of the virtual dataset (VDS) to include or exclude missing mapped elements.
    +//! [dapl_table] + * +//! [dxpl_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Data transfer property list functions (H5P)
    C FunctionPurpose
    #H5Pset_btree_ratios/#H5Pget_btree_ratiosSets/gets B-tree split ratios for a dataset transfer property list.
    #H5Pset_bufferMaximum size for the type conversion buffer and the background buffer. May also supply +pointers to application-allocated buffers.
    #H5Pset_data_transform/#H5Pget_data_transformSets/gets a data transform expression.
    #H5Pset_dataset_io_hyperslab_selectionSets a hyperslab file selection for a dataset I/O operation.
    #H5Pset_edc_check/#H5Pget_edc_checkSets/gets whether to enable error-detection when reading a dataset.
    #H5Pset_hyper_vector_sizeset the number of "I/O vectors" (offset and length pairs) which are to be +accumulated in memory before being issued to the lower levels +of the library for reading or writing the actual data.
    #H5Pset_filter_callbackSets user-defined filter callback function.
    #H5Pset_hyper_vector_size/#H5Pget_hyper_vector_sizeSets/gets number of I/O vectors to be read/written in hyperslab I/O.
    #H5Pset_type_conv_cb/#H5Pget_type_conv_cbSets/gets user-defined datatype conversion callback function.
    #H5Pset_vlen_mem_manager/#H5Pget_vlen_mem_managerSets/gets the memory manager for variable-length datatype allocation in #H5Dread and +#H5Dvlen_reclaim.
    #H5Pset_dxpl_mpio/#H5Pget_dxpl_mpioSets/gets data transfer mode.
    #H5Pset_dxpl_mpio_chunk_optSets a flag specifying linked-chunk I/O or multi-chunk I/O.
    #H5Pset_dxpl_mpio_chunk_opt_numSets a numeric threshold for linked-chunk I/O.
    #H5Pset_dxpl_mpio_chunk_opt_ratioSets a ratio threshold for collective I/O.
    #H5Pset_dxpl_mpio_collective_optSets a flag governing the use of independent versus collective I/O.
    #H5Pget_mpio_actual_chunk_opt_modeGets the type of chunk optimization that HDF5 actually performed on the last parallel I/O call.
    #H5Pget_mpio_actual_io_modeGets the type of I/O that HDF5 actually performed on the last parallel I/O call.
    #H5Pget_mpio_no_collective_causeGets local and global causes that broke collective I/O on the last parallel I/O call.
    H5Pset_preserve/H5Pget_preserveNo longer available, deprecated as it no longer has any effect.
    +//! [dxpl_table] + * +//! [gcpl_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Group creation property list functions (H5P)
    FunctionPurpose
    #H5Pall_filters_availVerifies that all required filters are available.
    #H5Pget_filterReturns information about a filter in a pipeline. The +C function is a macro: \see \ref api-compat-macros.
    #H5Pget_filter_by_idReturns information about the specified filter. The +C function is a macro: \see \ref api-compat-macros.
    #H5Pget_nfiltersReturns the number of filters in the pipeline.
    #H5Pmodify_filterModifies a filter in the filter pipeline.
    #H5Premove_filterDeletes one or more filters in the filter pipeline.
    #H5Pset_deflateSets the deflate (GNU gzip) compression method and compression level.
    #H5Pset_filterAdds a filter to the filter pipeline.
    #H5Pset_fletcher32Sets up use of the Fletcher32 checksum filter.
    #H5Pset_local_heap_size_hint#H5Pget_local_heap_size_hint/Sets/gets the anticipated maximum size of a local heap.
    #H5Pset_link_phase_changeSets the parameters for conversion between compact and dense groups.
    #H5Pget_link_phase_changeQueries the settings for conversion between compact and dense groups.
    #H5Pset_est_link_infoSets estimated number of links and length of link names in a group.
    #H5Pget_est_link_infoQueries data required to estimate required local heap or object header size.
    #H5Pset_nlinksSets maximum number of soft or user-defined link traversals.
    #H5Pget_nlinksRetrieves the maximum number of link traversals.
    #H5Pset_link_creation_orderSets creation order tracking and indexing for links in a group.
    #H5Pget_link_creation_orderQueries whether link creation order is tracked and/or indexed in a group.
    #H5Pset_char_encodingSets the character encoding used to encode a string. Use to set ASCII or UTF-8 character +encoding for object names.
    #H5Pget_char_encodingRetrieves the character encoding used to create a string.
    +//! [gcpl_table] + * +//! [gapl_table] + + + + + + + + + + +
    Group access property list functions (H5P)
    FunctionPurpose
    #H5Pset_all_coll_metadata_ops/#H5Pget_all_coll_metadata_opsSets/gets metadata I/O mode for read operations
    +//! [gapl_table] + * +//! [lapl_table] + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Link access property list functions (H5P)
    FunctionPurpose
    #H5Pset_elink_cb/#H5Pget_elink_cbSets/gets the external link traversal callback function.
    #H5Pset_elink_acc_flags/#H5Pget_elink_acc_flagsSets/gets the external link traversal file access flag.
    #H5Pset_elink_fapl/#H5Pget_elink_faplSets/gets a file access property list for use in accessing a file pointed to by an external link
    #H5Pset_elink_prefix/#H5Pget_elink_prefixSets/gets prefix to be applied to external link paths.
    #H5Pset_nlinks/#H5Pget_nlinksSets/gets maximum number of soft or user-defined link traversals.
    +//! [lapl_table] + * +//! [ocpl_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Object creation property list functions (H5P)
    FunctionPurpose
    #H5Pset_attr_creation_order/#H5Pget_attr_creation_orderSets/gets tracking and indexing of attribute creation order.
    #H5Pset_attr_phase_change/#H5Pget_attr_phase_changeSets/gets attribute storage phase change thresholds
    #H5Pset_filter/#H5Pget_filterAdds/gets a filter to/from the filter pipeline.
    #H5Pget_filter_by_idReturns information about a filter in a pipeline.
    #H5Pget_nfiltersReturns information about the specified filter.
    #H5Pset_obj_track_times/#H5Pget_obj_track_timesSets/gets the recording of times associated with an object.
    #H5Pmodify_filterModifies a filter in the filter pipeline.
    #H5Premove_filterDelete one or more filters in the filter pipeline.
    #H5Pset_fletcher32Sets up use of the Fletcher32 checksum filter.
    +//! [ocpl_table] + * +//! [ocpypl_table] + + + + + + + + + + + + + + + + + + + + + + +
    Object copy property list functions (H5P)
    FunctionPurpose
    #H5Padd_merge_committed_dtype_pathAdds a path to the list of paths that will be searched in the destination file for a matching committed datatype.
    #H5Pfree_merge_committed_dtype_pathsClears the list of paths stored in the object copy property list.
    #H5Pset_copy_object/#H5Pget_copy_objectSets/gets the properties to be used when an object is copied.
    #H5Pset_mcdt_search_cb/#H5Pget_mcdt_search_cbSets/gets the callback function that H5Ocopy() will invoke before searching for a matching committed datatype.
    +//! [ocpypl_table] + * +//! [strcpl_table] + + + + + + + + + + +
    String creation property list functions (H5P)
    FunctionPurpose
    #H5Pset_char_encoding/#H5Pget_char_encodingSets/gets the character encoding used to encode link and attribute names.
    +//! [strcpl_table] + * +//! [lcpl_table] + + + + + + + + + + +
    Link creation property list functions (H5P)
    FunctionPurpose
    #H5Pset_create_intermediate_group/#H5Pget_create_intermediate_groupSpecifies/retrieves whether to create missing intermediate groups.
    +//! [lcpl_table] + * +//! [acpl_table] + + + + + + + + + + +
    Attribute creation property list functions (H5P)
    FunctionPurpose
    #H5Pset_char_encoding/#H5Pget_char_encodingSets/gets the character encoding used to encode link and attribute names.
    +//! [acpl_table] + * + */ + \ No newline at end of file diff --git a/doxygen/examples/tables/volAPIs.dox b/doxygen/examples/tables/volAPIs.dox new file mode 100644 index 0000000..6b9df9b --- /dev/null +++ b/doxygen/examples/tables/volAPIs.dox @@ -0,0 +1,637 @@ +/** VOL API List + * +//! [vol_native_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Alphabetical list of HDF5 API calls specific to the native VOL connector
    APIDescription
    #H5Aget_num_attrsdeprecated
    #H5Aiterate1deprecated
    #H5Dchunk_iter
    H5DdebugInternal API routines
    H5Dformat_convertInternal API routines
    H5Dget_chunk_index_typeInternal API routines
    #H5Dget_chunk_info
    #H5Dget_chunk_info_by_coord
    #H5Dget_chunk_storage_size
    #H5Dget_num_chunks
    #H5Dget_offset
    #H5Dread_chunk
    #H5Dwrite_chunk
    H5FD*
    #H5Fclear_elink_file_cache
    H5Fformat_convertInternal API routines
    #H5Fget_dset_no_attrs_hint
    #H5Fget_eoa
    #H5Fget_file_image
    #H5Fget_filesize
    #H5Fget_free_sections
    #H5Fget_freespace
    #H5Fget_info1deprecated
    #H5Fget_info2
    #H5Fget_mdc_config
    #H5Fget_mdc_hit_rate
    #H5Fget_mdc_image_info
    #H5Fget_mdc_logging_status
    #H5Fget_mdc_size
    #H5Fget_metadata_read_retry_info
    #H5Fget_mpi_atomicity
    #H5Fget_page_buffering_stats
    #H5Fget_vfd_handle
    #H5Fincrement_filesize
    #H5Fis_hdf5deprecated
    #H5Freset_mdc_hit_rate_stats
    #H5Freset_page_buffering_stats
    #H5Fset_dset_no_attrs_hint
    #H5Fset_latest_formatdeprecated
    #H5Fset_libver_bounds
    #H5Fset_mdc_config
    #H5Fset_mpi_atomicity
    #H5Fstart_mdc_logging
    #H5Fstart_swmr_write
    #H5Fstop_mdc_logging
    #H5Gget_commentdeprecated
    #H5Giteratedeprecated
    #H5Gget_info
    #H5Gget_info_by_name
    #H5Gget_info_by_idx
    #H5Gget_objinfodeprecated
    #H5Gget_objname_by_idxdeprecated
    #H5Gget_objtype_by_idxdeprecated
    #H5Gset_commentdeprecated
    #H5Lget_info1deprecated
    #H5Lget_info_by_idx1deprecated
    #H5Literate1deprecated
    #H5Literate_by_name1deprecated
    #H5Lvisit1deprecated
    #H5Lvisit_by_name1deprecated
    #H5Oare_mdc_flushes_disabled
    #H5Odisable_mdc_flushes
    #H5Oenable_mdc_flushes
    #H5Oget_comment
    #H5Oget_comment_by_name
    #H5Oget_info_by_idx1deprecated
    #H5Oget_info_by_idx2deprecated
    #H5Oget_info_by_name1deprecated
    #H5Oget_info_by_name2deprecated
    #H5Oget_info1deprecated
    #H5Oget_info2deprecated
    #H5Oget_native_info
    #H5Oget_native_info_by_idx
    #H5Oget_native_info_by_name
    #H5Oopen_by_addrdeprecated
    #H5Oset_comment
    #H5Oset_comment_by_name
    #H5Ovisit1deprecated
    #H5Ovisit by name1deprecated
    #H5Ovisit2deprecated
    #H5Ovisit by name2deprecated
    +//! [vol_native_table] + * + * +//! [vol_independent_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Alphabetical list of VOL-independent HDF5 API calls
    APIDescription
    H5*
    #H5Dfill
    #H5Dgather
    #H5Diterate
    #H5Dscatter
    #H5Dvlen_reclaimdeprecated
    #H5Dvlen_get_buf_size
    H5E*
    H5I*
    #H5Lis_registered
    #H5Lregister
    #H5Lunpack_elink_val
    #H5Lunregister
    H5PL*
    H5P*
    H5S*
    H5T*non-committed
    H5VL*
    H5Z*
    +//! [vol_independent_table] + * + * +//! [vol_optional_table] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    List of Native VOL Optional Operation Values By Subclass
    SubclassAPI ReferenceDefinition
    H5VL_SUBCLS_ATTR#H5Aiterate (deprecated routine)#H5VL_NATIVE_ATTR_ITERATE_OLD
    H5VL_SUBCLS_DATASETH5Dformat_convert (internal)#H5VL_NATIVE_DATASET_FORMAT_CONVERT
    H5Dget_chunk_index_type (internal)#H5VL_NATIVE_DATASET_GET_CHUNK_INDEX_TYPE
    #H5Dget_chunk_storage_size#H5VL_NATIVE_DATASET_GET_CHUNK_STORAGE_SIZE
    #H5Dget_num_chunks#H5VL_NATIVE_DATASET_GET_NUM_CHUNKS
    #H5Dget_chunk_info#H5VL_NATIVE_DATASET_GET_CHUNK_INFO_BY_IDX
    #H5Dget_chunk_info_by_coord#H5VL_NATIVE_DATASET_GET_CHUNK_INFO_BY_COORD
    #H5Dread_chunk#H5VL_NATIVE_DATASET_CHUNK_READ
    #H5Dwrite_chunk#H5VL_NATIVE_DATASET_CHUNK_WRITE
    #H5Dvlen_get_buf_size#H5VL_NATIVE_DATASET_GET_VLEN_BUF_SIZE
    #H5Dget_offset#H5VL_NATIVE_DATASET_GET_OFFSET
    #H5Dget_offset#H5VL_NATIVE_DATASET_CHUNK_ITER
    H5VL_SUBCLS_FILE#H5Fclear_elink_file_cache#H5VL_NATIVE_FILE_CLEAR_ELINK_CACHE
    #H5Fget_file_image#H5VL_NATIVE_FILE_GET_FILE_IMAGE
    #H5Fget_free_sections#H5VL_NATIVE_FILE_GET_FREE_SECTIONS
    #H5Fget_freespace#H5VL_NATIVE_FILE_GET_FREE_SPACE
    #H5Fget_info1 / #H5Fget_info2#H5VL_NATIVE_FILE_GET_INFO
    #H5Fget_mdc_config#H5VL_NATIVE_FILE_GET_MDC_CONF
    #H5Fget_mdc_hit_rate#H5VL_NATIVE_FILE_GET_MDC_HR
    #H5Fget_mdc_size#H5VL_NATIVE_FILE_GET_MDC_SIZE
    #H5Fget_filesize#H5VL_NATIVE_FILE_GET_SIZE
    #H5Fget_vfd_handle#H5VL_NATIVE_FILE_GET_VFD_HANDLE
    #H5Freset_mdc_hit_rate_stats#H5VL_NATIVE_FILE_RESET_MDC_HIT_RATE
    #H5Fset_mdc_config#H5VL_NATIVE_FILE_SET_MDC_CONFIG
    #H5Fget_metadata_read_retry_info#H5VL_NATIVE_FILE_GET_METADATA_READ_RETRY_INFO
    #H5Fstart_swmr_write#H5VL_NATIVE_FILE_START_SWMR_WRITE
    #H5Fstart_mdc_logging#H5VL_NATIVE_FILE_START_MDC_LOGGING
    #H5Fstop_mdc_logging#H5VL_NATIVE_FILE_STOP_MDC_LOGGING
    #H5Fget_mdc_logging_status#H5VL_NATIVE_FILE_GET_MDC_LOGGING_STATUS
    H5Fformat_convert (internal)#H5VL_NATIVE_FILE_FORMAT_CONVERT
    #H5Freset_page_buffering_stats#H5VL_NATIVE_FILE_RESET_PAGE_BUFFERING_STATS
    #H5Fget_page_buffering_stats#H5VL_NATIVE_FILE_GET_PAGE_BUFFERING_STATS
    #H5Fget_mdc_image_info#H5VL_NATIVE_FILE_GET_MDC_IMAGE_INFO
    #H5Fget_eoa#H5VL_NATIVE_FILE_GET_EOA
    #H5Fincrement_filesize#H5VL_NATIVE_FILE_INCR_FILESIZE
    #H5Fset_latest_format/#H5Fset_libver_bounds#H5VL_NATIVE_FILE_SET_LIBVER_BOUNDS
    #H5Fget_dset_no_attrs_hint#H5VL_NATIVE_FILE_GET_MIN_DSET_OHDR_FLAG
    #H5Fset_dset_no_attrs_hint#H5VL_NATIVE_FILE_SET_MIN_DSET_OHDR_FLAG
    #H5Fget_mpi_atomicity#H5VL_NATIVE_FILE_GET_MPI_ATOMICITY
    #H5Fset_mpi_atomicity#H5VL_NATIVE_FILE_SET_MPI_ATOMICITY
    Adjust file after open, with wrapping context#H5VL_NATIVE_FILE_POST_OPEN
    H5VL_SUBCLS_GROUP#H5Giterate (deprecated routine)#H5VL_NATIVE_GROUP_ITERATE_OLD
    #H5Gget_objinfo (deprecated routine)#H5VL_NATIVE_GROUP_GET_OBJINFO
    H5VL_SUBCLS_OBJECT#H5Gget_comment, #H5Oget_comment, #H5Oget_comment_by_name#H5VL_NATIVE_OBJECT_GET_COMMENT
    #H5Gset_comment, #H5Oset_comment, #H5Oset_comment_by_name#H5VL_NATIVE_OBJECT_SET_COMMENT
    #H5Odisable_mdc_flushes#H5VL_NATIVE_OBJECT_DISABLE_MDC_FLUSHES
    #H5Oenable_mdc_flushes#H5VL_NATIVE_OBJECT_ENABLE_MDC_FLUSHES
    #H5Oare_mdc_flushes_disabled#H5VL_NATIVE_OBJECT_ARE_MDC_FLUSHES_DISABLED
    #H5Oget_native_info, #H5Oget_native_info_by_idx, #H5Oget_native_info_by_name#H5VL_NATIVE_OBJECT_GET_NATIVE_INFO/td> +
    +//! [vol_optional_table] + * + */ diff --git a/doxygen/hdf5_header.html b/doxygen/hdf5_header.html index 23f41f9..36a3265 100644 --- a/doxygen/hdf5_header.html +++ b/doxygen/hdf5_header.html @@ -21,7 +21,7 @@ $mathjax -
    Please, help us to better know about our user community by answering the following short survey: https://www.hdfgroup.org/website-survey/
    +
    Please, help us to better serve our user community by answering the following short survey: https://www.hdfgroup.org/website-survey/
    diff --git a/doxygen/hdf5doxy_layout.xml b/doxygen/hdf5doxy_layout.xml index f7c47bf..d156f2c 100644 --- a/doxygen/hdf5doxy_layout.xml +++ b/doxygen/hdf5doxy_layout.xml @@ -4,14 +4,13 @@ - - - - - + + + + diff --git a/src/H5Amodule.h b/src/H5Amodule.h index e3bfe6f..0c31f71 100644 --- a/src/H5Amodule.h +++ b/src/H5Amodule.h @@ -364,7 +364,7 @@ * will be ignored by HDF5. * * The use of ASCII or UTF-8 characters is determined by the character encoding property. See - * #H5Pset_char_encoding in the \ref RM. + * #H5Pset_char_encoding in the \ref RM. * *

    No Special I/O or Storage

    * diff --git a/src/H5Dmodule.h b/src/H5Dmodule.h index 00751a9..8d2f23a 100644 --- a/src/H5Dmodule.h +++ b/src/H5Dmodule.h @@ -182,250 +182,11 @@ * * * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - *
    Dataset creation property list functions (H5P)
    FunctionPurpose
    #H5Pset_layoutSets the type of storage used to store the raw data for a dataset.
    #H5Pget_layoutReturns the layout of the raw data for a dataset.
    #H5Pset_chunkSets the size of the chunks used to store a chunked layout dataset.
    #H5Pget_chunkRetrieves the size of chunks for the raw data of a chunked layout dataset.
    #H5Pset_deflateSets compression method and compression level.
    #H5Pset_fill_valueSets the fill value for a dataset.
    #H5Pget_fill_valueRetrieves a dataset fill value.
    #H5Pfill_value_definedDetermines whether the fill value is defined.
    #H5Pset_fill_timeSets the time when fill values are written to a dataset.
    #H5Pget_fill_timeRetrieves the time when fill value are written to a dataset.
    #H5Pset_alloc_timeSets the timing for storage space allocation.
    #H5Pget_alloc_timeRetrieves the timing for storage space allocation.
    #H5Pset_filterAdds a filter to the filter pipeline.
    #H5Pall_filters_availVerifies that all required filters are available.
    #H5Pget_nfiltersReturns the number of filters in the pipeline.
    #H5Pget_filterReturns information about a filter in a pipeline. - * The C function is a macro: \see \ref api-compat-macros.
    #H5Pget_filter_by_idReturns information about the specified filter. - * The C function is a macro: \see \ref api-compat-macros.
    #H5Pmodify_filterModifies a filter in the filter pipeline.
    #H5Premove_filterDeletes one or more filters in the filter pipeline.
    #H5Pset_fletcher32Sets up use of the Fletcher32 checksum filter.
    #H5Pset_nbitSets up use of the n-bit filter.
    #H5Pset_scaleoffsetSets up use of the scale-offset filter.
    #H5Pset_shuffleSets up use of the shuffle filter.
    #H5Pset_szipSets up use of the Szip compression filter.
    #H5Pset_externalAdds an external file to the list of external files.
    #H5Pget_external_countReturns the number of external files for a dataset.
    #H5Pget_externalReturns information about an external file.
    #H5Pset_char_encodingSets the character encoding used to encode a string. Use to set ASCII or UTF-8 character - * encoding for object names.
    #H5Pget_char_encodingRetrieves the character encoding used to create a string.
    + * \anchor dcpl_table_tag Dataset creation property list functions (H5P) + * \snippet{doc} tables/propertyLists.dox dcpl_table * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - *
    Dataset access property list functions (H5P)
    FunctionPurpose
    #H5Pset_bufferSets type conversion and background buffers.
    #H5Pget_bufferReads buffer settings.
    #H5Pset_chunk_cacheSets the raw data chunk cache parameters.
    #H5Pget_chunk_cacheRetrieves the raw data chunk cache parameters.
    #H5Pset_edc_checkSets whether to enable error-detection when reading a dataset.
    #H5Pget_edc_checkDetermines whether error-detection is enabled for dataset reads.
    #H5Pset_filter_callbackSets user-defined filter callback function.
    #H5Pset_data_transformSets a data transform expression.
    #H5Pget_data_transformRetrieves a data transform expression.
    #H5Pset_type_conv_cbSets user-defined datatype conversion callback function.
    #H5Pget_type_conv_cbGets user-defined datatype conversion callback function.
    #H5Pset_hyper_vector_sizeSets number of I/O vectors to be read/written in hyperslab I/O.
    #H5Pget_hyper_vector_sizeRetrieves number of I/O vectors to be read/written in hyperslab I/O.
    #H5Pset_btree_ratiosSets B-tree split ratios for a dataset transfer property list.
    #H5Pget_btree_ratiosGets B-tree split ratios for a dataset transfer property list.
    #H5Pset_vlen_mem_managerSets the memory manager for variable-length datatype allocation in #H5Dread and - * #H5Dvlen_reclaim.
    #H5Pget_vlen_mem_managerGets the memory manager for variable-length datatype allocation in #H5Dread and - * #H5Dvlen_reclaim.
    #H5Pset_dxpl_mpioSets data transfer mode.
    #H5Pget_dxpl_mpioReturns the data transfer mode.
    #H5Pset_dxpl_mpio_chunk_optSets a flag specifying linked-chunk I/O or multi-chunk I/O.
    #H5Pset_dxpl_mpio_chunk_opt_numSets a numeric threshold for linked-chunk I/O.
    #H5Pset_dxpl_mpio_chunk_opt_ratioSets a ratio threshold for collective I/O.
    #H5Pset_dxpl_mpio_collective_optSets a flag governing the use of independent versus collective I/O.
    #H5Pset_multi_typeSets the type of data property for the MULTI driver.
    #H5Pget_multi_typeRetrieves the type of data property for the MULTI driver.
    #H5Pset_small_data_block_sizeSets the size of a contiguous block reserved for small data.
    #H5Pget_small_data_block_sizeRetrieves the current small data block size setting.
    + * \anchor dapl_table_tag Dataset access property list functions (H5P) + * \snippet{doc} tables/propertyLists.dox dapl_table * * \subsection subsec_dataset_program Programming Model for Datasets * This section explains the programming model for datasets. @@ -1106,41 +867,7 @@ * the pipeline processing: the pipeline and filter operations are identical no matter what data access * mechanism is used. * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - *
    I/O file drivers
    File DriverDescription
    #H5FD_COREStore in memory (optional backing store to disk file).
    #H5FD_FAMILYStore in a set of files.
    #H5FD_LOGStore in logging file.
    #H5FD_MPIOStore using MPI/IO.
    #H5FD_MULTIStore in multiple files. There are several options to control layout.
    #H5FD_SEC2Serial I/O to file using Unix “section 2” functions.
    #H5FD_STDIOSerial I/O to file using Unix “stdio” functions.
    + * \snippet{doc} tables/propertyLists.dox lcpl_table * * Each file driver writes/reads contiguous blocks of bytes from a logically contiguous address * space. The file driver is responsible for managing the details of the different physical storage @@ -1157,29 +884,7 @@ * Data transfer properties set optional parameters that control parts of the data pipeline. The * function listing below shows transfer properties that control the behavior of the library. * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - *
    Data transfer property list functions
    C FunctionPurpose
    #H5Pset_bufferMaximum size for the type conversion buffer and the background buffer. May also supply - * pointers to application-allocated buffers.
    #H5Pset_hyper_vector_sizeset the number of "I/O vectors" (offset and length pairs) which are to be - * accumulated in memory before being issued to the lower levels - * of the library for reading or writing the actual data.
    #H5Pset_btree_ratiosSet the B-tree split ratios for a dataset transfer property list. The split ratios determine - * what percent of children go in the first node when a node splits.
    + * \snippet{doc} tables/fileDriverLists.dox file_driver_table * * Some filters and file drivers require or use additional parameters from the application program. * These can be passed in the data transfer property list. The table below shows file driver property @@ -1897,10 +1602,10 @@ allocated if necessary. * byte 0 * * - * ???????? - * ????SPPP - * PPPPPPPP - * PPPP???? + * ???????? + * ????SPPP + * PPPPPPPP + * PPPP???? * * * diff --git a/src/H5Dpublic.h b/src/H5Dpublic.h index db628a3..7cf4952 100644 --- a/src/H5Dpublic.h +++ b/src/H5Dpublic.h @@ -464,6 +464,9 @@ H5_DLL hid_t H5Dget_type(hid_t dset_id); * a copy of the dataset creation property list associated with * the dataset specified by \p dset_id. * + * The creation property list identifier should be released with + * H5Pclose() to prevent resource leaks. + * */ H5_DLL hid_t H5Dget_create_plist(hid_t dset_id); @@ -633,6 +636,7 @@ H5_DLL herr_t H5Dget_num_chunks(hid_t dset_id, hid_t fspace_id, hsize_t *nchunks */ H5_DLL herr_t H5Dget_chunk_info_by_coord(hid_t dset_id, const hsize_t *offset, unsigned *filter_mask, haddr_t *addr, hsize_t *size); + /** * -------------------------------------------------------------------------- * \ingroup H5D @@ -656,7 +660,7 @@ H5_DLL herr_t H5Dget_chunk_info_by_coord(hid_t dset_id, const hsize_t *offset, u * Iterate over all chunked datasets and chunks in a file. * \snippet H5D_examples.c H5Ovisit_cb * - * \since 1.12.3, 1.13.0 + * \since 1.12.3 * */ H5_DLL herr_t H5Dchunk_iter(hid_t dset_id, hid_t dxpl_id, H5D_chunk_iter_op_t cb, void *op_data); diff --git a/src/H5ESpublic.h b/src/H5ESpublic.h index 6b8b2a9..6180487 100644 --- a/src/H5ESpublic.h +++ b/src/H5ESpublic.h @@ -2,7 +2,7 @@ * Copyright by The HDF Group. * * All rights reserved. * * * - * This file is part of HDF5. The full HDF5 copyright notice, including * + * This file is part of HDF5. The full HDF5 copyright notice, including * * terms governing use, modification, and redistribution, is contained in * * the COPYING file, which can be found at the root of the source code * * distribution tree, or in https://www.hdfgroup.org/licenses. * @@ -28,12 +28,14 @@ /* Public Typedefs */ /*******************/ -/* Asynchronous operation status */ +/** + * Asynchronous operation status + */ typedef enum H5ES_status_t { - H5ES_STATUS_IN_PROGRESS, /* Operation(s) have not yet completed */ - H5ES_STATUS_SUCCEED, /* Operation(s) have completed, successfully */ - H5ES_STATUS_FAIL, /* An operation has completed, but failed */ - H5ES_STATUS_CANCELED /* Operation(s) has been canceled */ + H5ES_STATUS_IN_PROGRESS, /**< Operation(s) have not yet completed */ + H5ES_STATUS_SUCCEED, /**< Operation(s) have completed, successfully */ + H5ES_STATUS_CANCELED, /**< Operation(s) has been canceled */ + H5ES_STATUS_FAIL /**< An operation has completed, but failed */ } H5ES_status_t; /********************/ diff --git a/src/H5FDmpio.h b/src/H5FDmpio.h index ba508eb..a70f34b 100644 --- a/src/H5FDmpio.h +++ b/src/H5FDmpio.h @@ -104,10 +104,10 @@ H5_DLL herr_t H5Pset_fapl_mpio(hid_t fapl_id, MPI_Comm comm, MPI_Info info); * \param[out] info MPI-2 info object * \returns \herr_t * - * \details H5Pget_fapl_mpio() returns duplicates of the stored MPI communicator + * \details If the file access property list is set to the #H5FD_MPIO driver, + * H5Pget_fapl_mpio() returns duplicates of the stored MPI communicator * and Info object through the \p comm and \p info pointers, if those - * values are non-null. The file access property list must be set to the - * #H5FD_MPIO driver. + * values are non-null. * * Since the MPI communicator and Info object are duplicates of the * stored information, future modifications to the access property list diff --git a/src/H5FDpublic.h b/src/H5FDpublic.h index c66a46c..cd476b9 100644 --- a/src/H5FDpublic.h +++ b/src/H5FDpublic.h @@ -18,8 +18,13 @@ #ifndef H5FDpublic_H #define H5FDpublic_H -#include "H5public.h" -#include "H5Fpublic.h" /*for H5F_close_degree_t */ +/* Public headers needed by this file */ +#include "H5public.h" /* Generic Functions */ +#include "H5Fpublic.h" /* Files */ + +/*****************/ +/* Public Macros */ +/*****************/ #define H5_HAVE_VFL 1 /*define a convenient app feature test*/ #define H5FD_VFD_DEFAULT 0 /* Default VFL driver value */ @@ -462,7 +467,26 @@ H5_DLL herr_t H5FDtruncate(H5FD_t *file, hid_t dxpl_id, hbool_t closing); H5_DLL herr_t H5FDlock(H5FD_t *file, hbool_t rw); H5_DLL herr_t H5FDunlock(H5FD_t *file); -/* Allows querying a VFD ID for features before the file is opened */ +/** + * \ingroup H5FD + * + * \brief Allows querying a VFD ID for features before the file is opened + * + * \param[in] driver_id Virtual File Driver (VFD) ID + * \param[out] flags VFD flags supported + * + * \return \herr_t + * + * \details Queries a virtual file driver (VFD) for feature flags. Takes a + * VFD hid_t so it can be used before the file is opened. For example, + * this could be used to check if a VFD supports SWMR. + * + * \note The flags obtained here are just those of the base driver and + * do not take any configuration options (e.g., set via a fapl + * call) into consideration. + * + * \since 1.10.2 + */ H5_DLL herr_t H5FDdriver_query(hid_t driver_id, unsigned long *flags /*out*/); #ifdef __cplusplus diff --git a/src/H5Fmodule.h b/src/H5Fmodule.h index 523d6bf..6939f4a 100644 --- a/src/H5Fmodule.h +++ b/src/H5Fmodule.h @@ -411,204 +411,15 @@ * * * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - *
    File creation property list functions
    FunctionPurpose
    #H5Pset_userblock/#H5Pget_userblockSets/retrieves size of userblock.
    #H5Pset_sizes/#H5Pget_sizesSets/retrieves byte size of offsets and lengths used to address objects in HDF5 file.
    #H5Pset_sym_k/#H5Pget_sym_kSets/retrieves size of parameters used to control symbol table nodes.
    #H5Pset_istore_k/#H5Pget_istore_kSets/retrieves size of parameter used to control B-trees for indexing chunked datasets.
    #H5Pset_file_imageSets an initial file image in a memory buffer.
    #H5Pget_file_imageRetrieves a copy of the file image designated as the initial content and structure of a file.
    #H5Pset_shared_mesg_nindexes/#H5Pget_shared_mesg_nindexesSets or retrieves number of shared object header message indexes in file - * creation property list.
    #H5Pset_shared_mesg_indexConfigures the specified shared object header message index.
    #H5Pget_shared_mesg_indexRetrieves the configuration settings for a shared message index.
    #H5Pset_shared_mesg_phase_change/#H5Pget_shared_mesg_phase_changeSets or retrieves shared object header message storage phase change thresholds.
    #H5Pget_version
    + * \anchor fcpl_table_tag File creation property list functions (H5P) + * \snippet{doc} tables/propertyLists.dox fcpl_table * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - *
    File access property list functions
    FunctionPurpose
    #H5Pset_alignment/#H5Pget_alignmentSets/retrieves alignment properties.
    #H5Pset_cache/#H5Pget_cacheSets/retrieves metadata cache and raw data chunk cache parameters.
    #H5Pset_elink_file_cache_size/#H5Pget_elink_file_cache_sizeSets/retrieves the size of the external link open file cache from the specified - * file access property list.
    #H5Pset_gc_references/#H5Pget_gc_referencesSets/retrieves garbage collecting references flag.
    #H5Pset_family_offsetSets offset property for low-level access to a file in a family of files.
    #H5Pget_family_offsetRetrieves a data offset from the file access property list.
    #H5Pset_meta_block_size/#H5Pget_meta_block_sizeSets the minimum metadata blocksize or retrieves the current metadata block size setting.
    #H5Pset_mdc_configSet the initial metadata cache configuration in the indicated File Access Property List - * to the supplied value.
    #H5Pget_mdc_configGet the current initial metadata cache config-uration from the indicated File Access - * Property List.
    #H5Pset_sieve_buf_size/#H5Pget_sieve_buf_sizeSets/retrieves maximum size of data sieve buffer.
    #H5Pset_libver_boundsSets bounds on library versions, and indirectly format versions, to be used - * when creating objects.
    #H5Pget_libver_boundsRetrieves library version bounds settings that indirectly control the format - * versions used when creating objects.
    #H5Pset_small_data_block_sizeSets the size of a contiguous block reserved for small data.
    #H5Pget_small_data_block_sizeRetrieves the current small data block size setting.
    + * \anchor fapl_table_tag File access property list functions (H5P) + * \snippet{doc} tables/propertyLists.dox fapl_table + * + * \anchor fd_pl_table_tag File driver property list functions (H5P) + * \snippet{doc} tables/propertyLists.dox fd_pl_table * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - *
    File driver functions
    FunctionPurpose
    #H5Pset_driverSets a file driver.
    #H5Pget_driverReturns the identifier for the driver used to create a file.
    #H5Pget_driver_infoReturns a pointer to file driver information.
    #H5Pset_fapl_core/#H5Pget_fapl_coreSets the driver for buffered memory files (in RAM) or retrieves information regarding - * the driver.
    #H5Pset_fapl_direct/#H5Pget_fapl_directSets up use of the direct I/O driver or retrieves the direct I/O driver settings.
    #H5Pset_fapl_family/#H5Pget_fapl_familySets driver for file families, designed for systems that do not support files - * larger than 2 gigabytes, or retrieves information regarding driver.
    #H5Pset_fapl_logSets logging driver.
    #H5Pset_fapl_mpio/#H5Pget_fapl_mpioSets driver for files on parallel file systems (MPI I/O) or retrieves information - * regarding the driver.
    H5Pset_fapl_mpiposix/H5Pget_fapl_mpiposixNo longer available.
    #H5Pset_fapl_multi/#H5Pget_fapl_multiSets driver for multiple files, separating categories of metadata and raw data, - * or retrieves information regarding driver.
    #H5Pset_fapl_sec2Sets driver for unbuffered permanent files or retrieves information regarding driver.
    #H5Pset_fapl_splitSets driver for split files, a limited case of multiple files with one metadata file - * and one raw data file.
    #H5Pset_fapl_stdioSets driver for buffered permanent files.
    #H5Pset_fapl_windowsSets the Windows I/O driver.
    #H5Pset_multi_typeSpecifies type of data to be accessed via the MULTI driver enabling more direct access.
    #H5Pget_multi_typeRetrieves type of data property for MULTI driver.
    * * \subsection subsec_file_create Creating or Opening an HDF5 File * This section describes in more detail how to create and how to open files. @@ -865,100 +676,7 @@ * #H5FD_SEC2. Alternative layouts and drivers are designed to suit the needs of a variety of * systems, environments, and applications. The drivers are listed in the table below. * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - *
    Supported file drivers
    Driver NameDriver IdentifierDescriptionRelated API
    POSIX#H5FD_SEC2This driver uses POSIX file-system functions like read and write to perform I/O to a single, - * permanent file on local disk with no system buffering. This driver is POSIX-compliant and is - * the default file driver for all systems.#H5Pset_fapl_sec2
    Direct#H5FD_DIRECTThis is the #H5FD_SEC2 driver except data is written to or read from the file - * synchronously without being cached by the system.#H5Pset_fapl_direct
    Log#H5FD_LOGThis is the #H5FD_SEC2 driver with logging capabilities.#H5Pset_fapl_log
    Windows#H5FD_WINDOWSThis driver was modified in HDF5-1.8.8 to be a wrapper of the POSIX driver, - * #H5FD_SEC2. This change should not affect user applications.#H5Pset_fapl_windows
    STDIO#H5FD_STDIOThis driver uses functions from the standard C stdio.h to perform I/O - * to a single, permanent file on local disk with additional system buffering.#H5Pset_fapl_stdio
    Memory#H5FD_COREWith this driver, an application can work with a file in memory for faster reads and - * writes. File contents are kept in memory until the file is closed. At closing, the memory - * version of the file can be written back to disk or abandoned.#H5Pset_fapl_core
    Family#H5FD_FAMILYWith this driver, the HDF5 file’s address space is partitioned into pieces and sent to - * separate storage files using an underlying driver of the user’s choice. This driver is for - * systems that do not support files larger than 2 gigabytes.#H5Pset_fapl_family
    Multi#H5FD_MULTIWith this driver, data can be stored in multiple files according to the type of the data. - * I/O might work better if data is stored in separate files based on the type of data. The Split - * driver is a special case of this driver.#H5Pset_fapl_multi
    SplitH5FD_SPLITThis file driver splits a file into two parts. One part stores metadata, and the other part - * stores raw data. This splitting a file into two parts is a limited case of the Multi driver.#H5Pset_fapl_split
    Parallel#H5FD_MPIOThis is the standard HDF5 file driver for parallel file systems. This driver uses the MPI - * standard for both communication and file I/O.#H5Pset_fapl_mpio
    Parallel POSIXH5FD_MPIPOSIXThis driver is no longer available
    StreamH5FD_STREAMThis driver is no longer available.
    + * \snippet{doc} tables/fileDriverLists.dox supported_file_driver_table * * For more information, see the HDF5 Reference Manual entries for the function calls shown in * the column on the right in the table above. diff --git a/src/H5Gmodule.h b/src/H5Gmodule.h index a112a40..3946110 100644 --- a/src/H5Gmodule.h +++ b/src/H5Gmodule.h @@ -481,100 +481,7 @@ * * * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - *
    Group creation property list functions
    FunctionPurpose
    #H5Pall_filters_availVerifies that all required filters are available.
    #H5Pget_filterReturns information about a filter in a pipeline. The - * C function is a macro: \see \ref api-compat-macros.
    #H5Pget_filter_by_idReturns information about the specified filter. The - * C function is a macro: \see \ref api-compat-macros.
    #H5Pget_nfiltersReturns the number of filters in the pipeline.
    #H5Pmodify_filterModifies a filter in the filter pipeline.
    #H5Premove_filterDeletes one or more filters in the filter pipeline.
    #H5Pset_deflateSets the deflate (GNU gzip) compression method and compression level.
    #H5Pset_filterAdds a filter to the filter pipeline.
    #H5Pset_fletcher32Sets up use of the Fletcher32 checksum filter.
    #H5Pset_link_phase_changeSets the parameters for conversion between compact and dense groups.
    #H5Pget_link_phase_changeQueries the settings for conversion between compact and dense groups.
    #H5Pset_est_link_infoSets estimated number of links and length of link names in a group.
    #H5Pget_est_link_infoQueries data required to estimate required local heap or object header size.
    #H5Pset_nlinksSets maximum number of soft or user-defined link traversals.
    #H5Pget_nlinksRetrieves the maximum number of link traversals.
    #H5Pset_link_creation_orderSets creation order tracking and indexing for links in a group.
    #H5Pget_link_creation_orderQueries whether link creation order is tracked and/or indexed in a group.
    #H5Pset_create_intermediate_groupSpecifies in the property list whether to create missing intermediate groups.
    #H5Pget_create_intermediate_groupDetermines whether the property is set to enable creating missing intermediate groups.
    #H5Pset_char_encodingSets the character encoding used to encode a string. Use to set ASCII or UTF-8 character - * encoding for object names.
    #H5Pget_char_encodingRetrieves the character encoding used to create a string.
    + * \snippet{doc} tables/propertyLists.dox gcpl_table * * * @@ -1017,7 +924,7 @@ * containing thousands to millions of members. Links are stored in * a fractal heap and indexed with an improved B-tree. * \li The new implementation also enables the use of link names consisting of - * non-ASCII character sets (see H5Pset_char_encoding()) and is + * non-ASCII character sets (see #H5Pset_char_encoding) and is * required for all link types other than hard or soft links, e.g., * external and user-defined links (see the \ref H5L APIs). * diff --git a/src/H5Gpublic.h b/src/H5Gpublic.h index 74f0da7..a663395 100644 --- a/src/H5Gpublic.h +++ b/src/H5Gpublic.h @@ -120,7 +120,7 @@ extern "C" { * * \since 1.8.0 * - * \see H5Gopen2(), H5Gclose() + * \see H5Gopen2() * */ H5_DLL hid_t H5Gcreate2(hid_t loc_id, const char *name, hid_t lcpl_id, hid_t gcpl_id, hid_t gapl_id); @@ -167,7 +167,7 @@ H5_DLL hid_t H5Gcreate2(hid_t loc_id, const char *name, hid_t lcpl_id, hid_t gcp * H5Gclose() when the group is no longer needed so that resource * leaks will not develop. * - * \see H5Olink(), H5Dcreate(), \ref api-compat-macros + * \see H5Olink(), H5Gcreate() * * \since 1.8.0 * @@ -199,7 +199,7 @@ H5_DLL hid_t H5Gcreate_anon(hid_t loc_id, hid_t gcpl_id, hid_t gapl_id); * * \since 1.8.0 * - * \see H5Gcreate2(), H5Gclose() + * \see H5Gcreate2() * */ H5_DLL hid_t H5Gopen2(hid_t loc_id, const char *name, hid_t gapl_id); @@ -218,12 +218,10 @@ H5_DLL hid_t H5Gopen2(hid_t loc_id, const char *name, hid_t gapl_id); * property list associated with the group specified by \p group_id. * * The creation property list identifier should be released with - * H5Gclose() to prevent resource leaks. + * H5Pclose() to prevent resource leaks. * * \since 1.8.0 * - * \see H5Gcreate2(), H5Gclose() - * */ H5_DLL hid_t H5Gget_create_plist(hid_t group_id); @@ -250,8 +248,6 @@ H5_DLL hid_t H5Gget_create_plist(hid_t group_id); * * \since 1.8.0 * - * \see H5Gcreate2(), H5Gclose() - * */ H5_DLL herr_t H5Gget_info(hid_t loc_id, H5G_info_t *ginfo); @@ -284,8 +280,6 @@ H5_DLL herr_t H5Gget_info(hid_t loc_id, H5G_info_t *ginfo); * * \since 1.8.0 * - * \see H5Gcreate2(), H5Gclose() - * */ H5_DLL herr_t H5Gget_info_by_name(hid_t loc_id, const char *name, H5G_info_t *ginfo, hid_t lapl_id); @@ -331,8 +325,6 @@ H5_DLL herr_t H5Gget_info_by_name(hid_t loc_id, const char *name, H5G_info_t *gi * * \since 1.8.0 * - * \see H5Gcreate2(), H5Gclose() - * */ H5_DLL herr_t H5Gget_info_by_idx(hid_t loc_id, const char *group_name, H5_index_t idx_type, H5_iter_order_t order, hsize_t n, H5G_info_t *ginfo, hid_t lapl_id); @@ -360,8 +352,6 @@ H5_DLL herr_t H5Gget_info_by_idx(hid_t loc_id, const char *group_name, H5_index_ * * \since 1.8.0 * - * \see H5Gcreate2(), H5Gclose() - * */ H5_DLL herr_t H5Gflush(hid_t group_id); @@ -385,8 +375,6 @@ H5_DLL herr_t H5Gflush(hid_t group_id); * * \since 1.8.0 * - * \see H5Gcreate2(), H5Gclose() - * */ H5_DLL herr_t H5Grefresh(hid_t group_id); diff --git a/src/H5Lpublic.h b/src/H5Lpublic.h index 9e3084d..e487b0f 100644 --- a/src/H5Lpublic.h +++ b/src/H5Lpublic.h @@ -733,7 +733,7 @@ H5_DLL htri_t H5Lexists(hid_t loc_id, const char *name, hid_t lapl_id); * \p cset specifies the character set in which the link name is * encoded. Valid values include the following: * \csets - * This value is set with H5Pset_char_encoding(). + * This value is set with #H5Pset_char_encoding. * * \c token is the location that a hard link points to, and * \c val_size is the size of a soft link or user defined link value. @@ -888,10 +888,12 @@ H5_DLL ssize_t H5Lget_name_by_idx(hid_t loc_id, const char *group_name, H5_index * not been indexed by the index type, they will first be sorted by * that index then the iteration will begin; if the links have been * so indexed, the sorting step will be unnecessary, so the iteration - * may begin more quickly. + * may begin more quickly. Valid values include the following: + * \indexes * * \p order specifies the order in which objects are to be inspected - * along the index \p idx_type. + * along the index \p idx_type. Valid values include the following: + * \orders * * \p idx_p tracks the iteration and allows an iteration to be * resumed if it was stopped before all members were processed. It is @@ -1680,7 +1682,7 @@ typedef herr_t (*H5L_iterate1_t)(hid_t group, const char *name, const H5L_info1_ * \c cset specifies the character set in which the link name is * encoded. Valid values include the following: * \csets - * This value is set with H5Pset_char_encoding(). + * This value is set with #H5Pset_char_encoding. * * \c address and \c val_size are returned for hard and symbolic * links, respectively. Symbolic links include soft and external links @@ -1796,10 +1798,12 @@ H5_DLL herr_t H5Lget_info_by_idx1(hid_t loc_id, const char *group_name, H5_index * not been indexed by the index type, they will first be sorted by * that index then the iteration will begin; if the links have been * so indexed, the sorting step will be unnecessary, so the iteration - * may begin more quickly. + * may begin more quickly. Valid values include the following: + * \indexes * * \p order specifies the order in which objects are to be inspected - * along the index \p idx_type. + * along the index \p idx_type. Valid values include the following: + * \orders * * \p idx_p tracks the iteration and allows an iteration to be * resumed if it was stopped before all members were processed. It is diff --git a/src/H5MMpublic.h b/src/H5MMpublic.h index 70ac644..d4aba98 100644 --- a/src/H5MMpublic.h +++ b/src/H5MMpublic.h @@ -14,8 +14,6 @@ /*------------------------------------------------------------------------- * * Created: H5MMpublic.h - * Jul 10 1997 - * Robb Matzke * * Purpose: Public declarations for the H5MM (memory management) * package. diff --git a/src/H5Mpublic.h b/src/H5Mpublic.h index 25d3058..24d207c 100644 --- a/src/H5Mpublic.h +++ b/src/H5Mpublic.h @@ -208,6 +208,9 @@ H5_DLL hid_t H5Mget_val_type(hid_t map_id); * \details H5Mget_create_plist() returns an identifier for a copy of the * creation property list for a map object specified by \p map_id. * + * The creation property list identifier should be released with + * H5Pclose() to prevent resource leaks. + * * \since 1.12.0 * */ diff --git a/src/H5Opublic.h b/src/H5Opublic.h index cc131e1..a645592 100644 --- a/src/H5Opublic.h +++ b/src/H5Opublic.h @@ -304,7 +304,7 @@ H5_DLL hid_t H5Oopen_by_token(hid_t loc_id, H5O_token_t token); * * \return \hid_tv{object} * - * \details H5Open_by_idx() opens the nth object in the group specified by \p loc_id + * \details H5Oopen_by_idx() opens the nth object in the group specified by \p loc_id * and \p group_name. * * \p loc_id specifies a location identifier. diff --git a/src/H5PLextern.h b/src/H5PLextern.h index 7f3df5e..d136051 100644 --- a/src/H5PLextern.h +++ b/src/H5PLextern.h @@ -2,7 +2,7 @@ * Copyright by The HDF Group. * * All rights reserved. * * * - * This file is part of HDF5. The full HDF5 copyright notice, including * + * This file is part of HDF5. The full HDF5 copyright notice, including * * terms governing use, modification, and redistribution, is contained in * * the COPYING file, which can be found at the root of the source code * * distribution tree, or in https://www.hdfgroup.org/licenses. * diff --git a/src/H5PLmodule.h b/src/H5PLmodule.h index 66a24fd..fff1e95 100644 --- a/src/H5PLmodule.h +++ b/src/H5PLmodule.h @@ -2,7 +2,7 @@ * Copyright by The HDF Group. * * All rights reserved. * * * - * This file is part of HDF5. The full HDF5 copyright notice, including * + * This file is part of HDF5. The full HDF5 copyright notice, including * * terms governing use, modification, and redistribution, is contained in * * the COPYING file, which can be found at the root of the source code * * distribution tree, or in https://www.hdfgroup.org/licenses. * diff --git a/src/H5PLpublic.h b/src/H5PLpublic.h index 55ff594..a886375 100644 --- a/src/H5PLpublic.h +++ b/src/H5PLpublic.h @@ -2,7 +2,7 @@ * Copyright by The HDF Group. * * All rights reserved. * * * - * This file is part of HDF5. The full HDF5 copyright notice, including * + * This file is part of HDF5. The full HDF5 copyright notice, including * * terms governing use, modification, and redistribution, is contained in * * the COPYING file, which can be found at the root of the source code * * distribution tree, or in https://www.hdfgroup.org/licenses. * diff --git a/src/H5Pmodule.h b/src/H5Pmodule.h index c7ab3bd..04eb124 100644 --- a/src/H5Pmodule.h +++ b/src/H5Pmodule.h @@ -789,9 +789,9 @@ *
  • \ref subsec_file_property_lists
    • *
  • \ref subsubsec_file_examples_props
    • *
  • \ref subsubsec_file_examples_access
    • - *
  • "File creation property list functions (H5P)"
    • - *
  • "File access property list functions (H5P)"
    • - *
  • "File driver functions (H5P)"
    • + *
  • \ref dcpl_table_tag "Dataset creation property list functions (H5P)"
    • + *
  • \ref fapl_table_tag "File access property list functions (H5P)"
    • + *
  • \ref fd_pl_table_tag "File driver property list functions (H5P)"
    • * \li In the \ref sec_attribute chapter, see "Attribute creation property list functions (H5P)". * \li In the \ref sec_group chapter, see "Group creation property list functions (H5P)". * \li Property lists are discussed throughout \ref sec_dataset. @@ -799,16 +799,16 @@ * All property list functions are described in the \ref H5P section of the * \ref RM. The function index at the top of the page provides a categorized listing * grouped by property list class. Those classes are listed below: - * \li File creation properties - * \li File access properties - * \li Group creation properties - * \li Dataset creation properties - * \li Dataset access properties - * \li Dataset transfer properties - * \li Link creation properties - * \li Link access properties - * \li Object creation properties - * \li Object copy properties + * \li \ref FCPL + * \li \ref FAPL + * \li \ref GCPL + * \li \ref DCPL + * \li \ref DAPL + * \li \ref DXPL + * \li \ref LCPL + * \li \ref LAPL + * \li \ref OCPL + * \li \ref OCPYPL * * Additional categories not related to the class structure are as follows: * \li General property list operations @@ -894,135 +894,186 @@ * or writing data. Property lists can be modified by adding or changing * properties. Property lists are deleted by closing the associated handles. * - *
    Other external link functions
    - * - * - * - * - * - * - * - * - * - *
    CreateRead
    - * \snippet{lineno} H5P_examples.c create - * - * \snippet{lineno} H5P_examples.c read - *
    UpdateDelete
    - * \snippet{lineno} H5P_examples.c update - * - * \snippet{lineno} H5P_examples.c delete - *
    + * \ref PLCR + * \snippet{doc} tables/propertyLists.dox plcr_table + * + * \ref PLCR + * \snippet{doc} tables/propertyLists.dox plcra_table + * + * \ref PLCR / \ref OCPL / \ref GCPL + * \snippet{doc} tables/propertyLists.dox fcpl_table + * + * \ref PLCR + * \snippet{doc} tables/propertyLists.dox fapl_table + * \snippet{doc} tables/propertyLists.dox fd_pl_table + * + * \ref PLCR + * \snippet{doc} tables/propertyLists.dox lapl_table + * + * \ref PLCR / \ref OCPL + * \snippet{doc} tables/propertyLists.dox dcpl_table + * + * \ref PLCR / \ref LAPL + * \snippet{doc} tables/propertyLists.dox dapl_table + * + * \ref PLCR / \ref OCPL + * \snippet{doc} tables/propertyLists.dox gcpl_table + * + * \ref PLCR / \ref LAPL + * \snippet{doc} tables/propertyLists.dox gapl_table + * + * \ref PLCR + * \snippet{doc} tables/propertyLists.dox ocpl_table + * + * \ref PLCR + * \snippet{doc} tables/propertyLists.dox ocpypl_table + * + * \ref PLCR + * \snippet{doc} tables/propertyLists.dox strcpl_table + * + * \ref PLCR / \ref STRCPL + * \snippet{doc} tables/propertyLists.dox lcpl_table + * + * \ref PLCR / \ref STRCPL + * \snippet{doc} tables/propertyLists.dox acpl_table + * * * \defgroup STRCPL String Creation Properties + * \ingroup H5P * Currently, there are only two creation properties that you can use to control * the creation of HDF5 attributes and links. The first creation property, the * choice of a character encoding, applies to both attributes and links. * The second creation property applies to links only, and advises the library * to automatically create missing intermediate groups when creating new objects. - * \ingroup H5P + * + * \snippet{doc} tables/propertyLists.dox strcpl_table * * \defgroup LCPL Link Creation Properties - * The first creation property, the choice of a character encoding, applies to - * both attributes and links. - * The second creation property applies to links only, and advises the library - * to automatically create missing intermediate groups when creating new objects. * \ingroup STRCPL + * This creation property applies to links only, and advises the library + * to automatically create missing intermediate groups when creating new objects. + * + * \snippet{doc} tables/propertyLists.dox lcpl_table * * @see STRCPL * * \defgroup ACPL Attribute Creation Properties - * The creation property, the choice of a character encoding, applies to attributes. * \ingroup STRCPL + * The creation property, the choice of a character encoding, applies to attributes. + * + * \snippet{doc} tables/propertyLists.dox acpl_table * * @see STRCPL * * \defgroup LAPL Link Access Properties * \ingroup H5P * + * \snippet{doc} tables/propertyLists.dox lapl_table + * * \defgroup DAPL Dataset Access Properties + * \ingroup LAPL * Use dataset access properties to modify the default behavior of the HDF5 * library when accessing datasets. The properties include adjusting the size * of the chunk cache, providing prefixes for external content and virtual * dataset file paths, and controlling flush behavior, etc. These properties * are \Emph{not} persisted with datasets, and can be adjusted at runtime before * a dataset is created or opened. - * \ingroup LAPL + * + * \snippet{doc} tables/propertyLists.dox dapl_table * * \defgroup DCPL Dataset Creation Properties + * \ingroup OCPL * Use dataset creation properties to control aspects of dataset creation such * as fill time, storage layout, compression methods, etc. * Unlike dataset access and transfer properties, creation properties \Emph{are} * stored with the dataset, and cannot be changed once a dataset has been * created. - * \ingroup OCPL + * + * \snippet{doc} tables/propertyLists.dox dcpl_table * * \defgroup DXPL Dataset Transfer Properties + * \ingroup H5P * Use dataset transfer properties to customize certain aspects of reading * and writing datasets such as transformations, MPI-IO I/O mode, error * detection, etc. These properties are \Emph{not} persisted with datasets, * and can be adjusted at runtime before a dataset is read or written. - * \ingroup H5P + * + * \snippet{doc} tables/propertyLists.dox dxpl_table * * \defgroup FAPL File Access Properties + * \ingroup H5P * Use file access properties to modify the default behavior of the HDF5 * library when accessing files. The properties include selecting a virtual * file driver (VFD), configuring the metadata cache (MDC), control * file locking, etc. These properties are \Emph{not} persisted with files, and * can be adjusted at runtime before a file is created or opened. - * \ingroup H5P + * + * \snippet{doc} tables/propertyLists.dox fapl_table + * \snippet{doc} tables/propertyLists.dox fd_pl_table * * \defgroup FCPL File Creation Properties + * \ingroup GCPL * Use file creation properties to control aspects of file creation such * as setting a file space management strategy or creating a user block. * Unlike file access properties, creation properties \Emph{are} * stored with the file, and cannot be changed once a file has been * created. - * \ingroup GCPL * - * \defgroup GAPL General Access Properties - * The functions in this section can be applied to different kinds of property - * lists. + * \snippet{doc} tables/propertyLists.dox fcpl_table + * + * \defgroup GAPL Group Access Properties * \ingroup LAPL + * The functions in this section can be applied to group property lists. + * + * \snippet{doc} tables/propertyLists.dox gapl_table * * \defgroup GCPL Group Creation Properties + * \ingroup OCPL * Use group creation properties to control aspects of group creation such * as storage layout, compression, and link creation order tracking. * Unlike file access properties, creation properties \Emph{are} * stored with the group, and cannot be changed once a group has been * created. - * \ingroup OCPL + * + * \snippet{doc} tables/propertyLists.dox gcpl_table * * \defgroup PLCR Property List Class Root - * Use the functions in this module to manage HDF5 property lists. * \ingroup H5P + * Use the functions in this module to manage HDF5 property lists. + * + * \snippet{doc} tables/propertyLists.dox plcr_table * * \defgroup PLCRA Property List Class Root (Advanced) + * \ingroup H5P * You can create and customize user-defined property list classes using the * functions described below. Arbitrary user-defined properties can also * be inserted into existing property lists as so-called temporary properties. - * \ingroup H5P * + * \snippet{doc} tables/propertyLists.dox plcra_table * * \defgroup OCPL Object Creation Properties * \ingroup H5P * + * \snippet{doc} tables/propertyLists.dox ocpl_table + * * \defgroup OCPYPL Object Copy Properties * \ingroup H5P * + * \snippet{doc} tables/propertyLists.dox ocpypl_table + * * \defgroup FMPL File Mount Properties - * Empty property class. * \ingroup H5P + * Empty property class. * * * \defgroup TCPL Datatype Creation Properties - * TCPL isn't supported yet. * \ingroup OCPL + * TCPL isn't supported yet. * * * \defgroup TAPL Datatype Access Properties - * TAPL isn't supported yet. * \ingroup LAPL + * TAPL isn't supported yet. * * * diff --git a/src/H5Ppublic.h b/src/H5Ppublic.h index 8990922..366bf81 100644 --- a/src/H5Ppublic.h +++ b/src/H5Ppublic.h @@ -5675,6 +5675,9 @@ H5_DLL herr_t H5Pget_dset_no_attrs_hint(hid_t dcpl_id, hbool_t *minimize); * are null pointers then the corresponding information is not * returned. * + * \note On Windows, off_t is typically a 32-bit signed long value, which + * limits the valid offset that can be returned to 2 GiB. + * * \version 1.6.4 \p idx parameter type changed to unsigned. * \since 1.0.0 * @@ -8054,9 +8057,8 @@ H5_DLL herr_t H5Pget_mpio_no_collective_cause(hid_t plist_id, uint32_t *local_no uint32_t *global_no_collective_cause); #endif /* H5_HAVE_PARALLEL */ -/* Link creation property list (LCPL) routines */ /** - * \ingroup STRCPL + * \ingroup LCPL * * \brief Determines whether property is set to enable creating missing * intermediate groups @@ -8087,7 +8089,7 @@ H5_DLL herr_t H5Pget_mpio_no_collective_cause(hid_t plist_id, uint32_t *local_no */ H5_DLL herr_t H5Pget_create_intermediate_group(hid_t plist_id, unsigned *crt_intmd /*out*/); /** - * \ingroup STRCPL + * \ingroup LCPL * * \brief Specifies in property list whether to create missing * intermediate groups @@ -8469,9 +8471,8 @@ H5_DLL herr_t H5Pget_map_iterate_hints(hid_t mapl_id, size_t *key_prefetch_size size_t *key_alloc_size /*out*/); #endif /* H5_HAVE_MAP_API */ -/* String creation property list (STRCPL) routines */ /** - * \ingroup STRCPL + * \ingroup ACPL * * \brief Retrieves the character encoding used to create a link or * attribute name @@ -8500,7 +8501,7 @@ H5_DLL herr_t H5Pget_map_iterate_hints(hid_t mapl_id, size_t *key_prefetch_size */ H5_DLL herr_t H5Pget_char_encoding(hid_t plist_id, H5T_cset_t *encoding /*out*/); /** - * \ingroup STRCPL + * \ingroup ACPL * * \brief Sets the character encoding used to encode link and attribute * names diff --git a/src/H5Tmodule.h b/src/H5Tmodule.h index 83f7467..590a60c 100644 --- a/src/H5Tmodule.h +++ b/src/H5Tmodule.h @@ -3872,26 +3872,6 @@ filled according to the value of this property. The padding can be: * to HDF5 files and linked to groups as HDF5 datatype objects or so-called * \Emph{committed datatypes}. * - * - * - * - * - * - * - * - * - * - * - *
    CreateRead
    - * \snippet{lineno} H5T_examples.c create - * - * \snippet{lineno} H5T_examples.c read - *
    UpdateDelete
    - * \snippet{lineno} H5T_examples.c update - * - * \snippet{lineno} H5T_examples.c delete - *
    - * * \defgroup ARRAY Array Datatypes * \ingroup H5T * \defgroup ATOM Atomic Datatypes @@ -3912,33 +3892,36 @@ filled according to the value of this property. The padding can be: * * \defgroup PDT Predefined Datatypes * \ingroup H5T - * \details What is a predefined HDF5 datatype? - * \todo Fill in the blanks! * * \defgroup PDTCPU By CPU * \ingroup PDT * \details CPU-specific datatypes * \defgroup PDTALPHA DEC Alpha * \ingroup PDTCPU + * \snippet{doc} tables/predefinedDatatypes.dox predefined_dec_datatypes_table * \defgroup PDTX86 AMD & INTEL * \ingroup PDTCPU + * \snippet{doc} tables/predefinedDatatypes.dox predefined_intel_datatypes_table * \defgroup PDTMIPS SGI MIPS * \ingroup PDTCPU + * \snippet{doc} tables/predefinedDatatypes.dox predefined_mips_datatypes_table * * \defgroup PDTIEEE IEEE * \ingroup PDT * \details The IEEE floating point types in big- and little-endian byte orders. + * \snippet{doc} tables/predefinedDatatypes.dox predefined_ieee_datatypes_table * * \defgroup PDTSTD Standard Datatypes * \ingroup PDT * \details These are "standard" types. For instance, signed (2's complement) * and unsigned integers of various sizes in big- and little-endian * byte orders. + * \snippet{doc} tables/predefinedDatatypes.dox predefined_std_datatypes_table * * \defgroup PDTUNIX UNIX-specific Datatypes * \ingroup PDT * \details Types which are particular to Unix. - * \todo Fill in the blanks! + * \snippet{doc} tables/predefinedDatatypes.dox predefined_unix_datatypes_table * * \defgroup PDTNAT Native Datatypes * \ingroup PDT @@ -3952,13 +3935,16 @@ filled according to the value of this property. The padding can be: * \li The datatype \c LLONG corresponds C's \Code{long long} and * \c LDOUBLE is \Code{long double}. These types might be the same * as \c LONG and \c DOUBLE, respectively. + * \snippet{doc} tables/predefinedDatatypes.dox predefined_native_datatypes_table + * * \defgroup PDTC9x C9x Integer Datatypes * \ingroup PDTNAT * \details C9x integer types - * \todo Fill in the blanks! + * \snippet{doc} tables/predefinedDatatypes.dox predefined_c9x_datatypes_table * * \defgroup PDTS Strings * \ingroup PDT + * \snippet{doc} tables/predefinedDatatypes.dox predefined_string_datatypes_table * */ diff --git a/src/H5Tpublic.h b/src/H5Tpublic.h index 13e92f6..29008db 100644 --- a/src/H5Tpublic.h +++ b/src/H5Tpublic.h @@ -1083,7 +1083,7 @@ H5_DLLVAR hid_t H5T_NATIVE_UINT_FAST64_g; * When creating a fixed-length string datatype, \p size will * be the length of the string in bytes. The length of the * string in characters will depend on i the encoding used; see - * H5Pset_char_encoding(). + * #H5Pset_char_encoding. * * ENUMs created with this function have a signed native integer * base datatype. Use H5Tenum_create() if a different integer base diff --git a/src/H5VLmodule.h b/src/H5VLmodule.h index 1ad0c8d..9fc14ab 100644 --- a/src/H5VLmodule.h +++ b/src/H5VLmodule.h @@ -27,18 +27,18 @@ #define H5_MY_PKG_ERR H5E_VOL #define H5_MY_PKG_INIT YES -/** \page H5VL_UG The HDF5 VOL plugin +/** \page H5VL_UG The HDF5 Virtual Object Layer (VOL) * - * \section sec_vol The HDF5 VOL plugin + * \section sec_vol The HDF5 Virtual Object Layer (VOL) * - * \section subsec_vol_intro Introduction + * \subsection subsec_vol_intro Introduction * The virtual object layer is an abstraction layer in the HDF5 library that intercepts all API calls - * that could potentially access objects in an HDF5 container and forwards those calls to a VOL connector, - * which implements the storage. The user or application gets the benefit of using the familiar and - * widely-used HDF5 data model and API, but can map the physical storage of the HDF5 file and objects - * to storage that better meets the application's data needs. + * that could potentially access objects in an HDF5 container and forwards those calls to a VOL + * connector, which implements the storage. The user or application gets the benefit of using the + * familiar and widely-used HDF5 data model and API, but can map the physical storage of the HDF5 file + * and objects to storage that better meets the application’s data needs. * - * \section subsec_vol_abstract_layer The VOL Abstraction Layer + * \subsection subsec_vol_abstract_layer The VOL Abstraction Layer * The VOL lies just under the public API. When a storage-oriented public APIcall is made, the library * performs a few sanity checks on the input parameters and then immediately invokes a VOL callback, * which resolves to an implementation in the VOL connector that was selected when opening or creating @@ -74,11 +74,11 @@ * For more information about which calls go through the VOL and the mechanism by which this is implemented, * see the connector author and library internals documentation. * - * \section subsec_vol_connect VOL Connectors + * \subsection subsec_vol_connect VOL Connectors * A VOL connector can be implemented in several ways: * \li as a shared or static library linked to an application * \li as a dynamically loaded plugin, implemented as a shared library - * \li and even as an internal connector, built into the HDF5 libraryitself + * \li and even as an internal connector, built into the HDF5 library itself * * This section mostly focuses on external connectors, both libraries and plugins, as those are expected * to be much more common than internal implementations. @@ -122,7 +122,9 @@ * \todo Describe the VOL plugin life cycle. * * \defgroup ASYNC Asynchronous Functions - * \brief Asynchronous Functions + * \brief List of the asynchronous functions. + * \note The argument \p es_id associated with the asynchronous APIs is the \Emph{event set id}. See H5ES for + *context. * * \defgroup H5VLDEF Definitions * \ingroup H5VL -- cgit v0.12