[ET Trac] #1878: hdf5 deflate fragments memory

Roland Haas trac-noreply at einsteintoolkit.org
Fri Jan 3 14:20:14 CST 2025


#1878: hdf5 deflate fragments memory

 Reporter: Frank Löffler
   Status: new
Milestone: 
  Version: development version
     Type: enhancement
 Priority: minor
Component: Other

Comment (by Roland Haas):

Since the issue is caused by code in libhdf5 there is not much we can actually do about this. Even patching `H5Z_filter_deflate` in the tar file included in ExternalLibraries/HDF5 won’t fix the issue on most clusters since on most clusters we use the system installed HDF5 library. Looking at the API call [https://support.hdfgroup.org/documentation/hdf5/latest/group\_\_\_d\_c\_p\_l.html#gaf1f569bfc54552bdb9317d2b63318a0d](https://support.hdfgroup.org/documentation/hdf5/latest/group___d_c_p_l.html#gaf1f569bfc54552bdb9317d2b63318a0d) there is no option to specify the initial buffer size.  
  
A patch for the self-build library is in `rhaas/deflate` of [https://github.com/einsteinToolkit/ExternalLibraries-hdf5](https://github.com/einsteinToolkit/ExternalLibraries-hdf5) for all the good it might do. The 32bit size field in gzip files is no longer considered authorative \(fails to record uncompressed file sizes >2GB\).

I’d suggest to close this as “wontfix” since there is nothing that we can really do about this.

--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1878/hdf5-deflate-fragments-memory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einsteintoolkit.org/pipermail/trac/attachments/20250103/f16a0832/attachment.htm>


More information about the Trac mailing list