When I run it I think I am getting some extra processes. There are some
duplicates opening the same file and doing I/O on it at the same time.
Does the create_children() function needs a "return;" at the end of the
else block so that the children don't continue into the for loop and
fork again
There's a new io.tar.gz there now that fixes an bunch of warnings.
What I'm finding is the failures are really hard to reproduce, but on
the PPC hardware, seem most likely to happen when using 16 32 MB
buffers (NUMBUF 16, BUFFER_SIZE 32*1024*1024), with 4 cpus (./testio
/pvfs/da13-test/testio
The app does a sequential write, using a maximum of NUMBUF (currently
16) buffers for async writes, posts them one at a time with
pvfs2_aio_flush, and then checks the buffer before re-using it with
pvfs2_aio_check.
Then it does 'rewindfile', and immediately starts the read.. So if the
file is
Could you break down what the app is doing at a little bit higher level
in this time frame? (ie, how many writes is it posting, how many reads
is it posting, which are concurrent, when it calls wait for each).
From what I can tell, it looks like there are 30 total isys_io's
posted; the first
I have an IO shim for a fortran application that uses pvfs_isys_io and
pvfs_sys_wait directly, and when using the IB BMI module, I issue a
whole bunch of writes, but it looks like the last one doesn't actually
make it all the way to disk. I get a failure where I go back to read the
last 32M blo
