| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
copyright notice.
Tested platform:
Kagiso only since it is only a comment block change. If it works in one
machine, it should work in all, I hope. Still need to check the parallel
build on copper.
|
|
|
|
|
|
|
| |
The problem
came from the EOA for the whole MULTI file. It's taken out because it's
meaningless for MULTI file. Instead, each individual file has its EOA.
|
|
|
|
|
|
|
|
|
| |
haven't
been run in a while, so many of the source files were updated with
tracing macros, etc. No code changes by me.
Tested on kagiso and smirom.
|
|
|
|
|
|
|
| |
condition for H5_HAVE_DIRECT_ALIGN
not defined simply repeated the code above. Merged this part into the code above. No other
significant change.
|
|
|
|
|
|
|
| |
systems like copper and sleipnir
doesn't require alignment for Direct I/O. If this's true, write or read data just like sec2
does.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor generic property list initialization code to put property list
specific routines in property list modules, instead of scattered to the four
winds. Also, introduce property list class initialization objects, to make
adding new property list classes in the library easier.
Fix daily test failure by using H5Pget_elink_prefix() API routine instead
of looking at the "raw" generic property list information.
Tested on:
Mac OS X/32 10.4.8 (amazon)
FreeBSD/32 4.11 (sleipnir) w/threadsafe
Linux/32 2.4 (heping) w/C++ & FORTRAN
Linux/64 2.4 (mir) w/build-all & 1.6 compat
|
|
|
|
|
|
| |
partial I/O for reading data
may not work well for Direct I/O because of the requirement for data alignment. Took it out.
|
|
|
|
| |
checkin. Put it back in.
|
|
|
|
|
|
| |
made the test more complete by writing
two data sets. One is aligned, and the other isn't.
|
|
|
|
|
|
|
| |
size is set through
H5Pset_fapl_direct. It's been added to H5FD_direct_read in the previous checkin. Still, a test is
needed at later checkin.
|
|
|
|
|
|
|
|
|
|
|
| |
Packet Table
compression test.
Tested that the file is removed on juniper and heping.
Running reconfigure also regenerated the H5E* files (I think this means
somebody updated these files but didn't run reconfigure).
|
|
|
|
|
|
|
|
| |
from file. If the application
requests large data from file, to avoid using too much of memory for copying data from library's
own aligned buffer to application's (unaligned) buffer, this step is done in fragment. The next
step checkin is to handle writing data in fragment.
|
|
|
|
|
|
|
| |
yesterday. This function would be redundant
because the allocation function in H5FD.c H5FD_real_alloc actually has handled the aligned
allocation.
|
|
|
|
|
|
| |
should be set through
H5Pset_alignment.
|
|
|
|
|
|
|
|
| |
H5Pset_fapl_direct be a structure and passed
through driver info functions in H5FD_direct_open, H5FD_direct_read, and H5FD_direct_write. The
external change is to add a new API function H5Pget_fapl_direct to query 3 control values, the
memory boundary, file system block size, and the maximal buffer size for copying data.
|
|
|
|
|
|
|
|
| |
H5Pset_fapl_direct to control
memory boundary, file block size, and maximal copy buffer size; second in H5FD_direct_write and
H5FD_direct_read, the library checks whether data buffer is aligned. If it is, then write and
read the data directly instead of making a copy buffer.
|
|
|
|
|
|
| |
posix_memalign function but causes compiling
error on copper. Comment it out. It only gives a warning on SGI Altix.
|
|
Altix (cobalt). There's a configure
option --enable-direct-vfd/--disable-direct-vfd to enable/disable Direct I/O support. The default
is enabled. There's a small test in test/vfd.c. Another way to test it is to set environment
variable HDF5_DRIVER to "direct" and run "make check" in the test/ directory. There'll be some
further improvement in the following checkin including allowing user to provide memory boundary
value, file block size, and copying buffer size.
|