This page is under construction and subject to change.
This release includes changes in the HDF5 storage format. PLEASE NOTE that HDF5-1.10 and earlier releases cannot read files created with the new features described below that are marked with a *.
HDF5 1.12 introduces several new features in the HDF5 library:
- Chunk Query Functions
- Hyperslab Performance Improvements
- Update to References
- Virtual Object Layer (VOL) and Virtual File Drivers (VFDs)
Hyperslab Performance Improvements
VDS and Hyperslab performance have been improved dramatically.
Update to References (RFC) *
See the Update to References page for details on the changes in HDF5-1.12.
While the previous H5R API supported both object and region references, it was lacking in functionality and flexibility: there was no support for attribute or external references, and it was not suitable for use outside of native HDF5 files, a requirement of the virtual object layer (VOL). In order to support these features several functions were introduced:
- Create (H5R_CREATE*) functions were added for each reference type: object, dataset region and attribute.
- A function was added to release a reference (H5R_DESTROY). This is required because a region reference no longer modifies the original file.
- Functions were added to query references (H5R_GET*).
- Other functions were added to simplify or clarify the API.
RFC) *(VOL) and Virtual File Drivers (
See Virtual Object Layer and VIrtual File Drivers for more information.
Theis an abstraction layer within the HDF5 library that enables different methods for accessing data and objects that conform to the HDF5 data model. The VOL intercepts all HDF5 API calls that potentially modify data on disk and forwards those calls to a plugin "object driver". The data on disk can be a different format than the HDF5 format.
The plugins can actually store the objects in variety of ways. A plugin could, for example, have objects be distributed remotely over different platforms, provide a raw mapping of the model to the file system, or even store the data in other file formats (like native netCDF or HDF4 format). The user still gets the same data model where access is done to a single HDF5 “container”; however the plugin object driver translates from what the user sees to how the data is actually stored. Having this abstraction layer maintains the object model of HDF5 and allows better usage of new object storage file systems that are targeted for Exascale systems.