Below are the known Gotchas that currently exist in FileBench.
1. For ZFS, FileBench will export/import your pool
FileBench uses mmap and before it starts to collect statistics, it will unmap any data it has. ZFS currently doesn't evict that data from its ARC (its file system cache). So as part of the flushing the file system cache for ZFS, filebench(1BENCH) will export and re-import your pool. So don't go using it on your production server while its in use. If you desire to do so, you can modify the 'fs_flush' perl script in /usr/benchmarks/filebench/scripts.
Once ZFS is able to support the ability to invalidate its mmap'd cached files or FileBench is modified to stop using mmap, the need to export/import the pool will go away.
2. Properly size your parameters
Now that FileBench supports not only workloads that want to know how much work can be done in time X (such as multistreamread.f or fileserver.f), but also workloads that will tell you how much time it took to do a certain amount of work (such as bringover.f or createfiles.f), its important to properly size your parameters accordingly to your system. A profile that fits a small system might not necessarily fit a larger system. See these recommendations.
3. The syntax of .prof files is very picky
Currently, FileBench is very picky about how you write your profiles (the .prof files). Certain characters or the wrong number of spaces will make FileBench exit in an unfriendly way. The best way to avoid this is to 'cp' one of the existing profiles (in /usr/benchmarks/filebench/config) and edit where necessary. See RFE 6543078 "A ',' in the description field of a profile file breaks in a confusing manner".