I have several quick questions about the core file driver.
First, I see now that you can H5Fopen with core driver. Was that
available in 1.8.1 too?
Do I need to configure HDF5 with any special flags to get core or stdio
driver availablility in the lib? If so, if a driver is requested and it
is NOT available, what is the behavior? fall back to another available
driver or error?
Is it concievable on some systems that 'hand off' I/O work to other
processors (like BG/P), that H5Fclose on a file that was using the core
driver could return BEFORE the file's contents are actually on disk and
thereby potentially corrupt a later H5Fopen on that file? Or, is this
really a matter BELOW HDF5 with whatever filesystem it is running on?
Mark
···
--
Mark C. Miller, Lawrence Livermore National Laboratory
email: mailto:miller86@llnl.gov
(M/T/W) (925)-423-5901 (!!LLNL BUSINESS ONLY!!)
(Th/F) (530)-753-8511 (!!LLNL BUSINESS ONLY!!)
Hi Mark,
I have several quick questions about the core file driver.
First, I see now that you can H5Fopen with core driver. Was that
available in 1.8.1 too?
I can't remember, but it was available around the 1.8.1 or 1.8.2 timeframe. (Maybe Elena remembers for certain)
Do I need to configure HDF5 with any special flags to get core or stdio
driver availablility in the lib?
No, those are available by default.
If so, if a driver is requested and it is NOT available, what is the behavior? fall back to another available driver or error?
Hmm... - it would fail.
Is it conceivable on some systems that 'hand off' I/O work to other
processors (like BG/P), that H5Fclose on a file that was using the core
driver could return BEFORE the file's contents are actually on disk and
thereby potentially corrupt a later H5Fopen on that file? Or, is this
really a matter BELOW HDF5 with whatever filesystem it is running on?
If it was a problem, it would be a problem with the layer below HDF5. H5Fclose() won't return until it's flushed any modified data to disk (the entire file, in the case of the core VFD) and called close() on the underlying file handle. If the close-to-open semantics aren't honored by the file system and the file appeared corrupted when re-opened, it would be the file system's fault.
Quincey
···
On Dec 2, 2009, at 2:00 PM, Mark Miller wrote:
Hi Mark,
I have several quick questions about the core file driver.
First, I see now that you can H5Fopen with core driver. Was that
available in 1.8.1 too?
I can't remember, but it was available around the 1.8.1 or 1.8.2 timeframe. (Maybe Elena remembers for certain)
Hmm... I failed to find documentation, but according to the H5FD_core_open function source code, it was done in November 2006 and became available in 1.6.6 (Aug 2007)
Elena
···
On Dec 2, 2009, at 3:25 PM, Quincey Koziol wrote:
On Dec 2, 2009, at 2:00 PM, Mark Miller wrote:
Do I need to configure HDF5 with any special flags to get core or stdio
driver availablility in the lib?
No, those are available by default.
If so, if a driver is requested and it is NOT available, what is the behavior? fall back to another available driver or error?
Hmm... - it would fail.
Is it conceivable on some systems that 'hand off' I/O work to other
processors (like BG/P), that H5Fclose on a file that was using the core
driver could return BEFORE the file's contents are actually on disk and
thereby potentially corrupt a later H5Fopen on that file? Or, is this
really a matter BELOW HDF5 with whatever filesystem it is running on?
If it was a problem, it would be a problem with the layer below HDF5. H5Fclose() won't return until it's flushed any modified data to disk (the entire file, in the case of the core VFD) and called close() on the underlying file handle. If the close-to-open semantics aren't honored by the file system and the file appeared corrupted when re-opened, it would be the file system's fault.
Quincey
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
