fio
fio is an I/O tool meant to be used both for benchmark and stress/hardware verification. It has support for 13 different types of I/O engines (sync, mmap, libaio, posixaio, SG v3, splice, null, network, syslet, guasi, solarisaio, and more), I/O priorities (for newer Linux kernels), rate I/O, forked or threaded jobs, and much more. It can work on block devices as well as files. fio accepts job descriptions in a simple-to-understand text format. Several example job files are included. fio displays all sorts of I/O performance information. It supports Linux, FreeBSD, and OpenSolaris.
| Tags | Benchmark Filesystems |
|---|---|
| Licenses | GPL |
| Operating Systems | POSIX Linux BSD Solaris |
| Implementation | C |
Recent releases
- 10 Jul 2009 15:23
Changes: This release fixes completion latency numbers (they would read 0), an alignment bug, and a SIGBUS on Sparc, improves the speed of the mmap engine on 64-bit architectures, and adds support for asynchronous "verify" offload threads to speed "verify" workloads.
- 03 Jul 2009 11:46
Changes: O_DIRECT/direct IO was accidentally broken just before the 1.29 release. This release restores that functionality. It also removes the forced power-of-2 alignment restriction on O_DIRECT, since some combinations of operating systems and IO target may not have such a restriction.
- 02 Jul 2009 10:27
Changes: Fixes and improvements for the IO limiting rate option, a fix for submission latency numbers in some cases, and a fix for a bug in the job parser that would sometimes truncate the postfix value when multiple values were given. A continue_on_error option was added to allow a job to keep running if it sees non-fatal errors. A bug in the mmap engine with large files and 32-bit machines was fixed. Support for fdatasync() was added with the fdatasync option. An iomem_align option was added for fine-grained control over IO buffer memory alignment. The pre_read option was fixed and no longer attempts to pre-read on IO engines that cannot seek.
- 03 Jun 2009 12:51
Changes: Corruption of submission/completion latency logs for shared files was fixed. Blocksizes are included in latency logs. Compilation warnings on FreeBSD/Solaris were fixed. A "pre_read" option was added to pre-read files into memory before starting the job. exec_prerun/postrun now invokes a shell. Accuracy of disk util stats was improved. Large files are supported with an mmap engine on 32-bit architectures. ETA stats were improved with better throughput reporting, and IOPS reporting was added there too. The Arm architecture is now supported. The man page was fixed based on lintian.
- 22 Apr 2009 10:45
Changes: A crash with multiple files for a job was fixed. Reporting of throughput was corrected, as it was sometimes off by about 2.4%. IO logging is allowed for diskless engines. Support was added for different weights for reads and writes with the bssplit= option. A crash with engines not supporting get_file_size() was fixed. A sample SSD performance analysis job was added. A problem was fixed with IO offsets sometimes being too large, causing early exit of failed IO verification.
- All comments
Recent commentsHi Steve,
That's a good suggestion, I'll add that feature. I would appreciate if you would send me your modifications to make it work on OS X, so I can integrate that as well!
Jens
Hello
FIO is a great tool. I've been using it to help certify storage for realtime
operation on Macs (we ported it over to Mac OS X).
The latency log would be much more useful if it filled in the IO size along with
the block number. When I'm doing latency testing, I usually sort the output to
get an idea of the worst case IOs during the run. Because the latency log only
lists block numbers, I have to know the previous block number so I can do the
math to see how big the actual IO was. If it was logged in the file, I could
sort and not have to worry about the ordering. (I hope that makes sense)
Steve
On Linux, using posix aio will not utilize the native linux aio. You need to use libaio for that.
Hi,
what is the status of posix aio .
does linking with glibc utilizes the native linux aio ? or do i need to use libaio ?
Thanks,
Nir