From c3f817e9450fc1fda77ee5f63691d2e00d3481bc Mon Sep 17 00:00:00 2001 From: Quincey Koziol Date: Wed, 23 Jul 2003 16:36:08 -0500 Subject: [svn-r7260] Purpose: Checkpoint file format revisions. --- doc/html/H5.format.html | 1436 +++++++++++++++++++++++++++-------------------- 1 file changed, 837 insertions(+), 599 deletions(-) diff --git a/doc/html/H5.format.html b/doc/html/H5.format.html index 5494b20..5ecff0f 100644 --- a/doc/html/H5.format.html +++ b/doc/html/H5.format.html @@ -15,10 +15,15 @@ TABLE.format CAPTION { font-weight:bold; font-size:larger;} TABLE.note {border:none; text-align:right; width:80%;} -TABLE.desc { border:none; width:80%;} -TABLE.desc TH { } -TABLE.desc TR { } -TABLE.desc TD { } +TABLE.desc { border:solid; border-collapse:collapse; text-align:left; width:80%;} +TABLE.desc TR { vertical-align:top;} +TABLE.desc TH { border-style:ridge; font-size:larger; padding:4px; text-decoration:underline;} +TABLE.desc TD { border-style:ridge; padding:4px; } + +TABLE.list { border:none; } +TABLE.list TR { vertical-align:top;} +TABLE.list TH { border:none; text-decoration:underline;} +TABLE.list TD { border:none; } @@ -257,8 +262,8 @@ TABLE.desc TD { } items within the file, the size of each group page, and a group entry for the root object in the file. -

-

+
+
- + + + + + + - + - + - + @@ -325,30 +335,37 @@ TABLE.desc TD { }
of the size specified in "Size of Offsets.") +
HDF5 Super Block Layout @@ -299,19 +304,24 @@ TABLE.desc TD { }
Base AddressOIndexed Storage Internal Node K1Reserved (zero)1
Base AddressO
Address of Global Free-space HeapOAddress of Global Free-space HeapO
End of File AddressOEnd of File AddressO
Driver Information Block AddressODriver Information Block AddressO
+ (Items marked with an '1' the above table are +
+ new in version 1 of the superblock) +
-
+ -

-

- - - - +
+
+
Field NameDescription
+ + + - + - + signature.) +

+ +

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

+ - + - + - + - + - + - + without invalidating the internal offset locations. +

+ +

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

+ - + - + - + - + - + - - + + + + + + - + address. +

+ +

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

+ - + - - + - + not used. +

+ +

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

+ - + - + - + the group graph for the file. +

+ +

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

+
Field NameDescription
HDF5 File SignatureThis field contains a constant value and can be used to + +

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


- +
+
- + @@ -360,33 +377,33 @@ TABLE.desc TD { } - - - - - - - - - + + + + + + + + + - - - - - - - - - + + + + + + + + +
decimalDecimal: 137 72 68
hexadecimal894844460d0a1a0aHexadecimal:894844460d0a1a0a
ASCII C Notation\211HDF\r\n\032\nASCII C Notation:\211HDF\r\n\032\n

- This signature both identifies the file as an HDF5 file +

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 @@ -400,10 +417,15 @@ TABLE.desc TD { } under MS-DOS. The final line feed checks for the inverse of the CR-LF translation problem. (This is a direct descendent of the PNG file - signature.)
Version Number of the Super Block

This value is used to determine the format of the @@ -413,13 +435,16 @@ TABLE.desc TD { } determine how the information in the super block is formatted.

-

The only value currently valid in this field is '0', which - indicates that the super block is formatted as described above. + +

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

+ +

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

Version Number of the File Free-space Information

This value is used to determine the format of the @@ -429,10 +454,13 @@ TABLE.desc TD { } indicates that the free space index is formatted as described below.

+ +

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

Version Number of the Root Group Symbol Table Entry

This value is used to determine the format of the @@ -446,10 +474,13 @@ TABLE.desc TD { } indicates that the root group symbol table entry is formatted as described below.

+ +

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

Version Number of the Shared Header Message Format

This value is used to determine the format of the @@ -463,26 +494,41 @@ TABLE.desc TD { } indicates that shared header messages are formatted as described below.

+ +

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

Size of OffsetsThis value contains the number of bytes used to store + +

This value contains the number of bytes used to store addresses in the file. The values for the addresses of objects in the file are offsets relative to a base address, usually the address of the super block signature. This allows a wrapper to be added after the file is created - without invalidating the internal offset locations.
Size of LengthsThis value contains the number of bytes used to store - the size of an object. +

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 @@ -494,27 +540,34 @@ TABLE.desc TD { }

See the description of B-trees below.

+ +

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

Group Internal Node K -

Each internal node of a group B-tree will have - at least K pointers to other nodes but not more than 2K - pointers. If the group has only one internal - node then it might have fewer than K pointers. +

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

This value must be greater than zero.

See the description of B-trees below.

+ +

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

File Consistency FlagsThis value contains flags to indicate information + +

This value contains flags to indicate information about the consistency of the information contained within the file. Currently, the following bit flags are defined: @@ -533,39 +586,79 @@ TABLE.desc TD { } normal access to a file and only set after the file's consistency is guaranteed by the library or a consistency utility. +

+ +

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

Indexed Storage Internal Node K +

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

+

This value must be greater than zero. +

+

See the description of B-trees below. +

+ +

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

+
Base AddressThis is the absolute file address of the first byte of + +

This is the absolute file address of the first byte of the HDF5 data within the file. The library currently constrains this value to be the absolute file address of the super block itself when creating new files; future versions of the library may provide greater flexibility. Unless otherwise noted, all other file addresses are relative to this base - address.
Address of Global Free-space IndexFree-space management is not yet defined in the HDF5 + +

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

+ +

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

+
End of File AddressThis is the relative file address of the first byte past + +

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

This is the relative file address of the file driver @@ -574,17 +667,26 @@ TABLE.desc TD { } driver information block then this entry should be the undefined address.

+ +

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

Root Group Symbol Table EntryThis is the 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.
-
+

Disk Format: Level 0B - File Driver Info

@@ -594,62 +696,69 @@ TABLE.desc TD { } order to reopen a file. The format of the file driver information block is: -

-

- -
- Driver Information Block +
+
+ + - - - - - + + + + + - + - + - + - - + +
+ Driver Information Block
bytebytebytebyte
bytebytebytebyte
Version Reserved (zero)
Driver Information Size (4 bytes)

Driver Identification (8 bytes)


Driver Information




Driver Information (n bytes)
- +
-

-

- - - - +
+
+
Field NameDescription
+ + + - + - + - + - + - + - + prefix "NCSA". +

+ @@ -679,7 +793,7 @@ TABLE.desc TD { } H5FD_sb_decode functions.
Field NameDescription
VersionThe version number of the driver information block. The - file format documented here is version zero. +

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

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

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

+
Driver IdentificationThis is an eight-byte ASCII string without null + +

This is an eight-byte ASCII string without null termination which identifies the driver and version number of the Driver Information block. The predefined drivers supplied with the HDF5 library are identified by the @@ -658,6 +767,8 @@ TABLE.desc TD { } the original version then the last letter(s) of the identification will be replaced by a version number in ASCII. +

+

For example, the various versions of the family driver will be identified by NCSAfami, NCSAfam0, NCSAfam1, etc. @@ -665,10 +776,13 @@ TABLE.desc TD { } to eight characters. Subsequent identifiers will be created by substituting sequential numerical values for the final character, starting with zero.) -

+

+

Identification for user-defined drivers is arbitrary but should be unique and avoid the four character - prefix "NCSA".
-
+
@@ -708,97 +822,100 @@ TABLE.desc TD { } Aside from that difference, internal nodes and leaf nodes are identical. -

-

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

-

- - - - +
+
+
Field NameDescription
+ + + - + - + reconstructing a damaged file. +

+ - + -
Field NameDescription
SignatureThe ASCII character string "TREE" is + +

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 TypeEach B-link tree points to a particular type of data. + +

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

+ +
- - + + @@ -812,57 +929,73 @@ TABLE.desc TD { } - + - + damanged trees. +

+ - + values. +

+ - + is the undefined address. +

+ - + field is the undefined address. +

+ - + N child pointers and N+1 keys. +

+ - +

+ @@ -931,27 +1070,27 @@ TABLE.desc TD { }
Node TypeDescriptionNode TypeDescription
0
Node LevelThe node level indicates the level at which this node + +

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 - damanged trees.
Entries UsedThis determines the number of children to which this + +

This determines the number of children to which this node points. All nodes of a particular type of tree have the same maximum degree, but most nodes will point to less than that number of children. The valid child pointers and keys appear at the beginning of the node and the unused pointers and keys appear at the end of the node. The unused pointers and keys have undefined - values.
Address of Left SiblingThis is the relative file address of the left sibling of + +

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

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 PointersEach tree has 2K+1 keys with 2K + +

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.
KeyThe format and size of the key values is determined by + +

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 @@ -870,37 +1003,42 @@ TABLE.desc TD { } 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
+ + + that key describes. +
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
+ + - - + + - - + +
Bytes 1-4: Size of chunk in bytes.
Bytes 4-8
Bytes 4-8: Filter mask, a 32-bit bitfield indicating which filters have been applied to that chunk.
N 64-bit fields
N 64-bit fields: A 64-bit index indicating the offset of the chunk within the dataset where N is the number of dimensions of the dataset. For example, if @@ -911,7 +1049,8 @@ TABLE.desc TD { }
-
- +

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[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). @@ -1006,67 +1145,76 @@ TABLE.desc TD { } contains K symbols and the other contains K+1 symbols. -

-

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


Group Entries
- +
-

-

- - - - +
+
+
Field NameDescription
+ + + - + - + reconstructing a damaged file. +

+ - + - + of the group node) +

+ - + - + entries contain undefined values. +

+ - +
Field NameDescription
SignatureThe ASCII character string "SNOD" is + +

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

The version number for the group node. This document describes version 1. (There is no version '0' - of the group node)
Number of SymbolsAlthough all group nodes have the same length, + +

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

Each symbol has an entry in the group node. @@ -1074,10 +1222,11 @@ TABLE.desc TD { } There are 2K entries in each group node, where K is the "Group Leaf Node K" value from the super block. +

-
+

Disk Format: Level 1C - Group Entry

@@ -1088,124 +1237,138 @@ TABLE.desc TD { } include space for caching certain constant metadata from the object header. -

-

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


Scratch-pad Space (16 bytes)
- +
-
(Items marked with an 'O' the above table are
of the size specified in "Size of Offsets.") -
- +
-

-

- - - - +
+
+
Field NameDescription
+ + + - + - + terminated. +

+ - + - + cached in the scratch-pad space. +

+ - + - - + - + always set to zero. +

+ - + - + one. +

+
Field NameDescription
Name OffsetThis is the byte offset into the group local + +

This is the byte offset into the group local heap for the name of the object. The name is null - terminated.
Object Header AddressEvery object has an object header which serves as a + +

Every object has an object header which serves as a permanent location for the object's metadata. In addition to appearing in the object header, some metadata can be - cached in the scratch-pad space.
Cache TypeThe cache type is determined from the object header. + +

The cache type is determined from the object header. It also determines the format for the scratch-pad space:
- - - +
0
+ + + + + + - - + + - - + + - - + +
Type:Description:
0 No data is cached by the group entry. This is guaranteed to be the case when an object header has a link count greater than one.
1
1 Object header metadata is cached in the group entry. This implies that the group entry refers to another group.
2
2 The entry is a symbolic link. The first four bytes of the scratch-pad space are the offset into the local heap for the link value. The object header address will be undefined.
N
N Other cache values can be defined later and libraries that do not understand the new values will still work properly.
+

ReservedThese four bytes are present so that the scratch-pad + +

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 SpaceThis space is used for different purposes, depending + +

This space is used for different purposes, depending on the value of the Cache Type field. Any metadata about a dataset object represented in the scratch-pad space is duplicated in the object header for that @@ -1213,13 +1376,17 @@ TABLE.desc TD { } and the size of the dataspace for a dataset whose datatype is atomic and whose dataspace is fixed and less than four dimensions. +

+

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

Format of the Scratch-pad Space

@@ -1235,216 +1402,235 @@ TABLE.desc TD { } contains cached metadata for another object header in the following format: -

-

- -
- Object Header Scratch-pad Format +
+
+ + - - - - - + + + + + - - + + - - + +
+ Object Header Scratch-pad Format
bytebytebytebyte
bytebytebytebyte
Address of B-treeO
Address of B-treeO
Address of Name HeapO
Address of Name HeapO
- +
-
(Items marked with an 'O' the above table are
of the size specified in "Size of Offsets.") -
- +
-

-

- - - - +
+
+
Field NameDescription
+ + + - + - + - + - +
Field NameDescription
Address of B-treeThis is the file address for the root of the - group's B-tree. +

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

+
Address of Name HeapThis is the file address for the group's local - heap, in which are stored the group's symbol names. +

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 +

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

-

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

-

- - - - +
+
+
Field NameDescription
+ + + - + - + the start of the link value, which is null terminated. +

+
Field NameDescription
Offset to Link ValueThe value of a symbolic link (that is, the name of the + +

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

Disk Format: Level 1D - Local Heaps

-

A heap is a collection of small heap objects. Objects can be +

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

-

-

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

- - - - +
Field NameDescription
+ + + - + - + damaged file. +

+ - + - - + - + unused space in the heap holds a linked list of free blocks. +

+ - + - + undefined address if this is the + last free chunk) followed by "Size of Lengths" bytes that store + the size of this free chunk. +

+ - + - + file. +

+
Field NameDescription
SignatureThe ASCII character string "HEAP" + +

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.
VersionEach local heap has its own version number so that new + +

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

+
Data Segment SizeThe total amount of disk memory allocated for the heap + +

The total amount of disk memory allocated for the heap data. This may be larger than the amount of space required by the objects stored in the heap. The extra - unused space in the heap holds a linked list of free blocks.
Offset to Head of Free-listThis is the offset within the heap data segment of the + +

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 + free block). The free block contains "Size of Lengths" bytes that are the offset of the next free chunk (or the - undefined address - if this is the last free chunk) followed by <Size of Lengths> - bytes that store the size of this free chunk.
Address of Data SegmentThe data segment originally starts immediately after + +

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.
@@ -1453,7 +1639,7 @@ TABLE.desc TD { }

Disk Format: Level 1E - Global Heap

-

Each HDF5 file has a global heap which stores various types of +

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: @@ -1462,23 +1648,19 @@ TABLE.desc TD { } 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. - -

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

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

    +

    -

    The implementation of the heap makes use of the memory +

    The implementation of the heap makes use of the memory management already available at the file level and combines that with a new top-level object called a collection to achieve Goal B. The global heap is the set of all collections. @@ -1486,195 +1668,223 @@ TABLE.desc TD { } each collection contains one or more global heap objects. For the purposes of disk I/O and caching, a collection is treated as an atomic object. +

    -

    -

    - -
    - A Global Heap Collection +
    +
    + + - - - - - + + + + + - + - + - + - + - + - + - + - +
    + A Global Heap Collection
    bytebytebytebyte
    bytebytebytebyte
    Signature
    Version Reserved (zero)
    Collection Size

    Global Heap Object 1

    Global Heap Object 2

    ...

    Global Heap Object N

    Global Heap Object 0 (free space)
    - +
    -

    -

    - - - - +
    +
    +
    Field NameDescription
    + + + - + - + damaged file. +

    + - + - - + - + objects plus their overhead. +

    + - + - + - + -
    Field NameDescription
    SignatureThe ASCII character string "GCOL" + +

    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.
    VersionEach collection has its own version number so that new + +

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

    +
    Collection Data SizeThis is the size in bytes of the entire collection + +

    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 and which allows for 170 16-byte heap - objects plus their overhead.
    Global Heap Object 1 through NThe objects are stored in any order with no - intervening unused space. +

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

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

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

    +
    -
    + -

    -

    - -
    - Global Heap Object +
    +
    + + - - - - - + + + + + - + - + - - + + - +
    + Global Heap Object
    bytebytebytebyte
    bytebytebytebyte
    Object ID Reference Count
    Reserved
    Object Data SizeL
    Object Data SizeL

    Object Data
    - +
    -
    (Items marked with an 'L' the above table are
    of the size specified in "Size of Lengths.") -
    - +
    -

    -

    - - - - +
    +
    +
    Field NameDescription
    + + + - + - + collection. +

    + - + - + count for Object 0 is always zero. +

    + - + - + - - + + + - + - +
    Field NameDescription
    Object IDEach object has a unique identification number within a + +

    Each object has a unique identification number within a collection. The identification numbers are chosen so that new objects have the smallest value possible with the exception that the identifier 0 always refers to the object which represents all free space within the - collection.
    Reference CountAll heap objects have a reference count field. An + +

    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.
    ReservedZero padding to align next field on an 8-byte - boundary. +

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

    +
    Object Size This is the size of the the fields - above plus the object data stored for the object. The - actual storage size is rounded up to a multiple of - eight.
    Object Size +

    This is the size of the the fields above plus the object data + stored for the object. The actual storage size is rounded up to a + multiple of eight. +

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

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

    +
    -
    +

    Disk Format: Level 1F - Free-space Index

    @@ -1686,7 +1896,7 @@ TABLE.desc TD { } that pointer is currently required to be the undefined address. -

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

    The format of the free-space index is not defined at this time. + Type: 0x0000
    + Length: varies
    + Status: Optional, may be repeated.
    + Purpose and Description: The NIL message is used to + indicate a message which is to be ignored when reading the header messages + for a data object. + [Possibly one which has been deleted for some reason.]
    + Format of Data: Unspecified.
    +

    Name: Simple Dataspace

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

    The Simple Dataspace message describes the number +

    The Simple Dataspace message describes the number of dimensions and size of each dimension that the data object has. This message is only used for datasets which have a simple, rectilinear grid layout; datasets requiring a more @@ -2002,8 +2253,8 @@ TABLE.desc TD { } must use the Complex Dataspace message for expressing the space the dataset inhabits. (Note: The Complex Dataspace functionality is - not yet implemented (as of HDF5 Release 1.2). It is not described - in this document.) + not yet implemented. It is not described in this document.) +

    @@ -2436,9 +2687,6 @@ TABLE.desc TD { }
    Grid Point Locations
    .
    .
    - -

    Examples:

    - Need some good examples, this is complex! --> @@ -3167,11 +3415,6 @@ TABLE.desc TD { } of dataset data, so the format will be determined by the dataset format. - -

    Name: Data Storage - External Data Files

    @@ -4095,11 +4338,6 @@ the file. - -

    Name: Group Message

    Type: 0x0011
    -- cgit v0.12