llnl / ior Goto Github PK

Hello

I'm having the following error when benchmarking the HDF5 method on a Blue Gene Q: "HDF5ERROR in aiori-HDF5.c (line 553): cannot create data set."

I'm using zlib/1.2.7 and hdf5/1.8.10, and compiling for the compute nodes (not front nodes).

The output is in this attachment below:

The file creation parameters are in this attachment below:

I use the latest git master branch version (v. 3.0.1)
The MPIIO and POSIX tests work fine.

Thank you for your support.

PS: As per contract with IBM, I was told by my line manager that we have to use to the version 2.10.3 of IOR... is this version fully compatible with Blue Gene Q? Any known issues?

Currently IOR only supports 1-dimensional HDF5 datasets. It would be interesting to support for multi-dimensional datasets such as the one that Parallel-NetCDF has. We can give the user the ability to choose the dimensions of the datasets and ideally the decomposition.

I can start working on this addition and do a pull request once it is done and get reviews from the community. But before that, I would like to hear form other users about such an addition.

This repo is dead. But it pops up first when you google 'IOR github.' The fork at
https://github.com/IOR-LANL/ior
is the only maintained public IOR repo. Who owns this repo and ignores it . . . .

ROMIO allows you to prefix a file with something to specify a file system driver and override ROMIO's automatic detection. We might do this if, for example, PVFS is available, but the kernel module is not installed (pvfs:/path/to/pvfs/testfile), or if we simply wish to avoid the overhead of stat (ufs:/regular/unix/file_system)

When IOR attempts to remove a file with such a prefix, it makes a call to the POSIX routine access(), but does not remove the prefix before doing so. access() does not return F_OK, naturally, and so does not attempt to remove the file. IOR doesn't complain about this, so we ended up thinking we were running tests of "create a new file" when actually we were "reusing existing file."

Hello,
when i am using the hdf5 api, collective mode, the underlying system
tries to do file locking (ADIOI_Set_lock).
After doing some investigation, I think I have found the reason:

In aiori-HDF5.c, the line 295

memDataSpaceDims[0] = (hsize_t) param->transferSize;

invokes strided io in the romio ADIO layer (ad_write_str). The line should be

memDataSpaceDims[0] = (hsize_t) param->transferSize / sizeof(IOR_size_t);

After changing this line of code, the configuration works without file locking.

ior isn't building on my system due to some missing GPFS symbols. Here are the errors:

mpicc -g -O2 -o ior ior.o utilities.o parse_options.o aiori-POSIX.o aiori-MPIIO.o -lm
aiori-POSIX.o: In function gpfs_access_end': /u/mx/co/mrobbert/ior/src/aiori-POSIX.c:165: undefined reference togpfs_fcntl'
aiori-POSIX.o: In function gpfs_access_start': /u/mx/co/mrobbert/ior/src/aiori-POSIX.c:141: undefined reference togpfs_fcntl'
aiori-POSIX.o: In function gpfs_free_all_locks': /u/mx/co/mrobbert/ior/src/aiori-POSIX.c:118: undefined reference togpfs_fcntl'
collect2: ld returned 1 exit status

I was able to get it to link properly by adding -lgpfs to the link lines. I can try to work up a patch, but it looks like this would need to be changed in the Autoconf files and I don't have much experience with those.

At line 433:
MPI_CHECK(MPI_File_open(testComm, testFileName, MPI_MODE_RDONLY, MPI_INFO_NULL, &fd), "cannot open file to get file size");
Always passes testComm to MPI_File_open regardless of value of test->filePerProc
When running in file per proc it breaks after initial file inflation.

Should be something like

IOR_offset_t MPIIO_GetFileSize(IOR_param_t * test, MPI_Comm testComm,
                               char *testFileName)
{
        IOR_offset_t aggFileSizeFromStat, tmpMin, tmpMax, tmpSum;
        MPI_File fd;
        MPI_Comm comm = testComm;

        if (test->filePerProc == TRUE)
                comm = MPI_COMM_SELF;

        MPI_CHECK(MPI_File_open(comm, testFileName, MPI_MODE_RDONLY,
                                MPI_INFO_NULL, &fd),
                  "cannot open file to get file size");
        MPI_CHECK(MPI_File_get_size(fd, (MPI_Offset *) & aggFileSizeFromStat),
                  "cannot get file size");

or maybe having the if below that re-arranged with opening file inside it.

Hi,

utilities.h needs to be included in parse_options.c as so that StringToBytes is forward declared. Otherwise the return value is treated as an int rather than IOR_size_t which causes errors when the block size is 2GB+.

Mark

Is there a time frame for a new IOR release? I find myself telling folks around here to use my fork but i'd rather see them use livermore's version.

Hello

I installed the latest IOR (3.0.1) on ubuntu Ubuntu 12.04.2 LTS.

Im running tests on HDF5-1.8.4 (Parallel), with an MPI implementation of MPICH2 (1.4.1), and libhdf5-mpich-1.8.4.

I installed the following dependencies via apt-get: libhdf5-mpi-dev libhdf5-mpich-1.8.4 libhdf5-mpich-dev

For building:
./bootstrap
./configure --with-hdf5=yes

For running my tests:
(1) ./src/ior -a POSIX
(2) ./src/ior -a MPIIO
(3) ./src/ior -a HDF5

Results:
(1) and (2) finished successfully. The (3) terminates abruptly with either "PMPI_Bcast(1438): Invalid datatype" or "PMPI_Bcast(1448): Null Datatype pointer"

I'm sending you as a comment the output of the (3) with verbosity level 5.

Your help is appreciated.
Many thanks.

Configure finds gpfs.h and gpfs_hcntl.h

checking gpfs.h usability... yes
checking gpfs.h presence... yes
checking for gpfs.h... yes
checking gpfs_fcntl.h usability... yes
checking gpfs_fcntl.h presence... yes
checking for gpfs_fcntl.h... yes

However 'make errors out -
mpicc -g -O2 -o ior ior.o utilities.o parse_options.o aiori-POSIX.o aiori-MPIIO.o -lm
aiori-POSIX.o: In function gpfs_free_all_locks':/home/xxxx/ior-master/src/aiori-POSIX.c:118: undefined reference togpfs_fcntl'
aiori-POSIX.o: In function gpfs_access_start': /home/xxxx/ior-master/src/aiori-POSIX.c:141: undefined reference togpfs_fcntl'
aiori-POSIX.o: In function gpfs_access_end': /home/xxxx/ior-master/src/aiori-POSIX.c:165: undefined reference togpfs_fcntl'
collect2: error: ld returned 1 exit status
make[1]: *** [ior] Error 1
make[1]: Leaving directory `/home/xxxx/ior-master/src'
make: *** [all] Error 2

Thought this issue was fixed #15, however i'm running in to same trouble.

consider an Ior hintfile with the line
IOR_HINT__MPI__cb_buffer_size = 1234

The spaces around '=' mean IOR tries to set the hint "cb_buffer_size ". It's easy to miss the extra space in the -H output, and you go crazy wondering why MPI is ignoring this hint.

Please apply the attached patch to make hintfile parsing not care so much about whitespace:

From e3475ee6e0b367d3f5fb7a43106a31e8d999f055 Mon Sep 17 00:00:00 2001
From: Rob Latham <[email protected]>
Date: Thu, 19 Dec 2013 13:01:35 -0600
Subject: [PATCH] more tolerant of whitepace in hintfile

If a hintfile contains e.g. cb_buffer_size = 1234, IOR will try to set
the hint "cb_buffer_size " (note trailing space), a hint that no MPI
implementation actually supports.

---
 src/utilities.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/utilities.c b/src/utilities.c
index 61b4f851..ce653611 100644
--- a/src/utilities.c
+++ b/src/utilities.c
@@ -162,8 +162,8 @@ void ExtractHint(char *settingVal, char *valueVal, char *hintString)
 {
         char *settingPtr, *valuePtr, *tmpPtr1, *tmpPtr2;

-        settingPtr = (char *)strtok(hintString, "=");
-        valuePtr = (char *)strtok(NULL, " \t\r\n");
+        settingPtr = (char *)strtok(hintString, " =");
+        valuePtr = (char *)strtok(NULL, " =\t\r\n");
         tmpPtr1 = settingPtr;
         tmpPtr2 = (char *)strstr(settingPtr, "IOR_HINT__MPI__");
         if (tmpPtr1 == tmpPtr2) {
-- 
1.8.3.2

When running a single-shared-file write test using at least two tasks, running on different nodes, using the POSIX api, IOR fails with the following error:

ior ERROR: write() failed, errno 22, Invalid argument (aiori-POSIX.c:236)
application called MPI_Abort(MPI_COMM_WORLD, -1) - process 1

Tests were conducted with IOR 3.0.1 and 2.10.3, using MPICH 3.2 and OrangeFS 2.9.3 as the backend file system. All compute and storage nodes run a CentOS 6.7 Linux, with kernel 2.6.32-573.22.1.el6.x86_64.

The parameters to reproduce the problem are:
mpiexec -n 2 -f mpihosts ior -wvvvv -t 1m -o /mnt/orangefs/testfile

ior unlinks files from the root file system (/)

This was noticed when compiling and running ior on a rhel/centos 7 system due to bin / sbin / lib / lib64 now being symbolic links.

Once ior runs on a rhel / centos 7 system the following error will occur when using executables requiring libraries within /lib / lib64:

i.e. when executing "ls"
-bash: /usr/bin/ls: /lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

You will need to relink these directories.

This issue is also apparent on centos 6.6 as testfiles created within root are unlinked.

During a strace the unlink can be seen:

unlink("//i_am_a_test_file_in_root") = 0

i_am_a_test_file_in_root was created prior to running ior and is no longer there afterwards.

The hint config file mechanism is nice but i'd like to see IOR go one step further and parse the environment for hints. Could keep the same format: e.g.

$  IOR_HINT__MPI__cb_nodes=5 ior -f ior.conf

Hi, I have built IOR with Pnetcdf and when I run the command "mpirun -n 4 ./ior -a NCMPI", it came with errors below:

ERROR in aiori-NCMPI.c (line 288): cannot write to data set.
ERROR: NetCDF: Not a valid data type or _FillValue type mismatch.

Could anyone tell me how to fix this problem?

Issue: undefined references to 'rpl_malloc' when cross compiling

Cause: AC_FUNC_MALLOC is based on a run-time test

When cross-compiling, the run-time test cannot run, so autoconf assumes non-gnu-libc behavior

(I found this link helpful: http://wiki.buici.com/xwiki/bin/view/Programing+C+and+C%2B%2B/Autoconf+and+RPL_MALLOC )

Platform: Blue Gene /P (but probably /L and maybe /Q?)

mpicc  -g -O2   -o ior ior.o utilities.o parse_options.o aiori-POSIX.o aiori-MPIIO.o     -lm
ior.o: In function `HumanReadable':
../../src/ior.c:917: undefined reference to `rpl_malloc'
ior.o: In function `CreateTest':
../../src/ior.c:583: undefined reference to `rpl_malloc'
ior.o: In function `AllocResults':
../../src/ior.c:532: undefined reference to `rpl_malloc'
../../src/ior.c:536: undefined reference to `rpl_malloc'
../../src/ior.c:541: undefined reference to `rpl_malloc'

I can work around this with an environment variable but if you could toss a 'rpl_malloc' in IOR to keep cross compilers happy, that would be great.