The report function is not supported code, and can be expected to change between versions of the library. Use it at your own risk.

The trace file is a debuging feature that allows the capture of top level metadata cache requests for purposes of debugging and/or optimization. This field should normally be set to 0, as trace file collection imposes considerable overhead.

This field should only be set to 1 when the trace_file_name contains the full path of the desired trace file, and either there is no open trace file on the cache, or the close_trace_file field is also 1.

The trace file feature is unsupported unless used at the direction of The HDF Group. It is intended to allow The HDF Group to collect a trace of cache activity in cases of occult failures and/or poor performance seen in the field, so as to aid in reproduction in the lab. If you use it absent the direction of The HDF Group, you are on your own.

See the above comments on the open_trace_file field. This field should be set to 0 unless there is an open trace file on the cache that you wish to close.

The trace file feature is unsupported unless used at the direction of The HDF Group. It is intended to allow The HDF Group to collect a trace of cache activity in cases of occult failures and/or poor performance seen in the field, so as to aid in reproduction in the lab. If you use it absent the direction of The HDF Group, you are on your own.

In the parallel case, an ascii representation of the mpi rank of the process will be appended to the file name to yield a unique trace file name for each process.

The length of the path must not exceed H5AC__MAX_TRACE_FILE_NAME_LEN characters.

The trace file feature is unsupported unless used at the direction of The HDF Group. It is intended to allow The HDF Group to collect a trace of cache activity in cases of occult failures and/or poor performance seen in the field, so as to aid in reproduction in the lab. If you use it absent the direction of The HDF Group, you are on your own.

In rare circumstances, the raw data throughput requirements may be so high that the user wishes to postpone metadata writes so as to reserve I/O throughput for raw data. The evictions_enabled field exists to allow this. However, this is an extreme step, and you have no business doing it unless you have read the User Guide section on metadata caching, and have considered all other options carefully.

The evictions_enabled field may not be set to disabled (0) unless all adaptive cache resizing code is disabled via the incr_mode, flash_incr_mode, and decr_mode fields.

When this flag is set to disabled (0), the metadata cache will not attempt to evict entries to make space for new entries, and thus will grow without bound.

Evictions will be re-enabled when this field is set back to 1. This should be done as soon as possible.

The value must lie in the interval [0.0, 1.0]. 0.01 is a good place to start in the serial case. In the parallel case, a larger value is needed -- see Metadata Caching in HDF5 in the collection “Advanced Topics in HDF5.”

H5C_incr__off: Automatic cache size increase is disabled, and the remaining increment fields are ignored.

H5C_incr__threshold: Automatic cache size increase is enabled using the hit rate threshold algorithm.

When the hit rate over an epoch is below this threshold and the cache is full, the maximum size of the cache is multiplied by increment (below), and then clipped as necessary to stay within max_size, and possibly max_increment.

This field must lie in the interval [0.0, 1.0]. 0.8 or 0.9 is a good starting point.

The actual cache size increase will be clipped to satisfy the max_size specified in the general configuration, and possibly max_increment below.

The parameter must be greater than or equal to 1.0 -- 2.0 is a reasonable value.

If you set it to 1.0, you will effectively disable cache size increases.

H5C_flash_incr__off: Flash cache size increase is disabled.

H5C_flash_incr__add_space: Flash cache size increase is enabled using the add space algorithm.

At present, this value must lie in the range [0.1, 1.0].

At present, this field must lie in the range [0.1, 10.0].

H5C_decr__off: Automatic cache size decrease is disabled.

H5C_decr__threshold: Automatic cache size decrease is enabled using the hit rate threshold algorithm.

H5C_decr__age_out: Automatic cache size decrease is enabled using the ageout algorithm.

H5C_decr__age_out_with_threshold: Automatic cache size decrease is enabled using the ageout with hit rate threshold algorithm

When decr_mode is H5C_decr__threshold, and the hit rate over a given epoch exceeds the supplied threshold, the current maximum cache size is multiplied by decrement to obtain a tentative new (and smaller) maximum cache size.

When decr_mode is H5C_decr__age_out_with_threshold, there is no attempt to find and evict aged out entries unless the hit rate in the previous epoch exceeded the supplied threshold.

This field must lie in the interval [0.0, 1.0].

For H5C_incr__threshold, .9995 or .99995 is a good place to start.

For H5C_decr__age_out_with_threshold, .999 might be more useful.

The actual cache size decrease will be clipped to satisfy the min_size specified in the general configuration, and possibly max_decrement below.

The parameter must be be in the interval [0.0, 1.0].

If you set it to 1.0, you will effectively disable cache size decreases. 0.9 is a reasonable starting point.

When so directed, the ageout based algorithms will not decrease the maximum cache size unless the empty reserve can be met.

The parameter must lie in the interval [0.0, 1.0]. 0.1 or 0.05 is a good place to start.

Synchronization occurs whenever the number of bytes of dirty metadata created since the last synchronization exceeds this limit.

This field only applies to the parallel case. While it is ignored elsewhere, it can still draw a value out of bounds error.

It must be consistant across all caches on any given file.

By default, this field is set to 256 KB. It shouldn't be more than half the current maximum cache size times the minimum clean fraction.