fs-test / fs_test Goto Github PK

The fs_test code does this basically:

malloc(buffer, iosize)
memset(buff, rank, iosize)
start_timer()
if barrier_before_open barrier()
open_file()
if barrier_after_open barrier()
end_timer()

For large IO sizes, the malloc and the memset can take a while AND they can be highly variable. Therefore the time difference between the slowest rank to malloc/memset and the fastest rank to malloc/memset shows up in our open time.

The fix is easy: just add a barrier before the start_timer. By the way, I figured this out because the slow open can hurt the effective write bandwidth if you're not measuring with huge amounts of data.

flatten_file should only be called on N-1 workloads and when io is "plfs". So, first check the use of the "flatten" flag for such. Then, fix flatten index to check those conditions and clean-up the code a bit in there.

We have the following statement / question with regard to fs_test. Can you clarify for us?

Our benchmarker’s discovered what they believe is a bug while validating our benchmark results using fs_test.
Can you let us know if this is a bug and how you would want to handle this situation.

We noticed this comment at the start of fs_test.c:
TODO:
read should be affected by time limit also
pass min and max blocks when time limit used

Looking further, we noticed there is a “compute_amount_written”
function, but no corresponding function to compute the amount read.
It appears that all the bandwidth numbers printed in the read output
section are actually based on the amount of data written.

This is only accurate if all the data that was written gets read.
The command line options specified in the RFP cause fs_test to write and
read for the same amount of time. For a variety of reasons, the read test
may hit the time limit before all the data that was written gets read.
In that case, the actual read rate would be slower than the write rate,
but fs_test will report the Effective Bandwidth of the two tests to be essentially
the same since the max write and max read times will be nearly identical.

Is this the intended behavior, or should fs_test compute the actual amount of
data read during a fixed time test in order to print the accurate read bandwidth?

There is an error when I build the fs_test:
mpicc -g -I. -DROMIO -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D__USE_LARGEFILE64=1 fs_test.o utilities.o print.o hashtable.o hashtable_itr.o boolean.o -o fs_test.x
/usr/bin/ld: fs_test.o: undefined reference to symbol 'floor@@GLIBC_2.2.5'
/usr/lib64/libm.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [fs_test] Error 1
How can I fix it ?

plfs_open, plfs_getattr, etc don't use the new interface