FileBench affectionados,

I have just uploaded a webrev of a set of bug fixes and other 
modifications to FileBench to the OpenSolaris.org webrev site. This set 
of changes started out as modification to essentially merge "files" into 
"filesets", but ended up addressing a number of related issues. Here are 
the details:

This started out as just a fix for bug:

6601818 Turn FileBench "files" into filesets with 1 entry.

However, to do this properly, found it helped to fix / implement five 
other outstanding bug / feature requests:

6601341 flowop_endop() needs to have the actual number of bytes of I/O 
done passed to it

6581691 pre-allocation is molasses

6568378 Flowop reads and writes should be consistent about memory buffer 
usage

6595374 "tf_memsize smaller than IO size" error when reading/writing 
large file

6564960 filebench should handle larger iosize's or gracefully error out 
with a nicer message

To make reviewing easier, here are some comments about the individual 
bugs that were fixed and the files that were changed as part of each 
bug's specific fix.

6601818 Turn FileBench "files" into filesets with 1 entry:

Basically, this involves changes to parser_gram.y so that the "define 
files" command creates a fileset with entry size of 1. It is implemented 
by creating a new subroutine "parser_fileset_define_common" which 
allocates a fileset and fills in all attributes that are common between 
files and filesets. The old parser_file_define() calls that, and sets 
default values to fileset things that don't apply when only a single 
entry (i.e. "files") is involved. Similarly, parser_fileset_define() 
first uses the common routine then sets attributes specific to filesets. 
Also, fileset.c and fileset.h were modified to support raw devices as a 
special case for filesets, (replacing the raw device mode for files, 
which, incidentally, was not enabled). Also, during testing I discovered 
that a subtle difference between files and filesets for "non allocated" 
files. Files actually create a file of size 0 at the specified path in 
that case, while filesets don't create a file at all. After consultation 
with other Sun engineers, I decided to leave the "file" behavior as "no 
file", and modify the two workloads that depend on having a file of size 
0 to specifically request the "alloc" of  0 length file.  Thus for both 
filesets (as was the case before) and the "new" files, leaving off the 
"alloc" attribute will result in no initial file creation on the disk.

As part of this fix, I needed to preserve the parallel allocation 
feature of files, so filesets can now be allocated in parallel, with up 
to 32 allocation threads running across all filesets and their 
constituent files, addressing:

6581691 pre-allocation is molasses

The changes to turn files into filesets also involved removing the 
"files" code path from the seven flowops that do I/O, and replacing it 
with some special code to handle raw devices. Also a few changes to the 
create / open / close / delete flowops. There was a lot of (almost) 
duplicate code here which I was planning to eliminate as part of:

6568378 Flowop reads and writes should be consistent about memory buffer 
usage

so I decided to tackle that one too. I created a common routine to 
select filesetentries, determine memory buffer pointers and file 
offsets. As mentioned, the "files" portion disappeared as part of that. 
Also, the selection of memory locations to read or write to was unified. 
If thread memory has been specified (tf_memsize > 0), then a random 
offset into tf_mem is calculated and passed back to the calling routine. 
Otherwise, a private fo_buf is allocated or reused, with its location 
passed back. The private buffer is created to be large enough to hold 
fo_iosize worth of bytes, which may be much larger than the old method 
of only allocating 1 MB. Thus, we keep track of the size of the buffer, 
and free(), malloc() a new one if the existing one is too small. Thus, 
this change also addresses:

6564960 filebench should handle larger iosize's or gracefully error out 
with a nicer message

If tf_mem is in use, it already will provide an error message if iosize 
is larger than tf_mem size, and that now applies to all seven I/O 
flowops (read, write, aiowrite, readwholefile, writewholefile, 
appendfile, appendfilerand). if tf_mem is not specified or set to 0 
size, then private buffers (fo_buf) will be allocated of iosize.

The old readwholefile and writewholefile ignored any supplied iosize 
(actually set it to the file size AFTER the first execution of the 
flowop), and arbitrarily broke the request into 1 megabyte chunks. This 
size gives full performance with many current disk drives and file 
systems, but not all, and can be too small for full performance with 
some RAIDed systems. So, for backwards compatibility, if iosize is 0 
(what the legacy workloads use for those two flowops), they will read or 
write the entire file in one I/O. Note that the thread memory, if it 
exists, must be at least as large as the largest size the file(s) can 
be. If iosize is set, the whole file will be read or written in "iosize" 
increments (or whatever is left of the file on the last I/O). So, if you 
have thread memory of 10 MB, you can set iosize to 10 MB (or less) to 
prevent "tf_mem too small" errors.

Changing readwholefile and writewholefile to do multiple iosize 
transfers, instead of multiple 1 MB transfers) until the whole file was 
read or written necessitated fixing:

6601341 flowop_endop() needs to have the actual number of bytes of I/O 
done passed to it

So that correct accounting of transfered bytes occurs. This also makes 
the accounting more accurate for sequential reads which can do less than 
iosize reads when they hit the end of the file. Finally, it fixes:

6595374 "tf_memsize smaller than IO size" error when reading/writing 
large file

which was caused by the way readwholefile and writewholefile manipulated 
iosize so the old flowop_endop() would (almost) do correct bytes 
transfered accounting.

The webrev for all of this has been posted to OpenSolaris.org at:
http://cr.opensolaris.org/~dreww/filebench_files2filesets 
<http://cr.opensolaris.org/%7Edreww/filebench_files2filesets>

Looking forward to your comments.

Drew Wilson

_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org

Reply via email to