Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 1 | fio |
| 2 | --- |
| 3 | |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 4 | fio is a tool that will spawn a number of threads or processes doing a |
| 5 | particular type of io action as specified by the user. fio takes a |
| 6 | number of global parameters, each inherited by the thread unless |
| 7 | otherwise parameters given to them overriding that setting is given. |
| 8 | The typical use of fio is to write a job file matching the io load |
| 9 | one wants to simulate. |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 10 | |
Jens Axboe | 2b02b54 | 2005-12-08 15:29:14 +0100 | [diff] [blame] | 11 | |
| 12 | Source |
| 13 | ------ |
| 14 | |
| 15 | fio resides in a git repo, the canonical place is: |
| 16 | |
| 17 | git://brick.kernel.dk/data/git/fio.git |
| 18 | |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 19 | Snapshots are frequently generated and they include the git meta data as |
| 20 | well. You can download them here: |
Jens Axboe | 2b02b54 | 2005-12-08 15:29:14 +0100 | [diff] [blame] | 21 | |
| 22 | http://brick.kernel.dk/snaps/ |
| 23 | |
Jens Axboe | 1053a10 | 2006-06-06 09:23:13 +0200 | [diff] [blame] | 24 | Pascal Bleser <guru@unixtech.be> has fio RPMs in his repository, you |
| 25 | can find them here: |
| 26 | |
| 27 | http://linux01.gwdg.de/~pbleser/rpm-navigation.php?cat=System/fio |
| 28 | |
Jens Axboe | 2b02b54 | 2005-12-08 15:29:14 +0100 | [diff] [blame] | 29 | |
Jens Axboe | bbfd6b0 | 2006-06-07 19:42:54 +0200 | [diff] [blame] | 30 | Building |
| 31 | -------- |
| 32 | |
| 33 | Just type 'make' and 'make install'. If on FreeBSD, for now you have to |
| 34 | specify the FreeBSD Makefile with -f, eg: |
| 35 | |
| 36 | $ make -f Makefile.Freebsd && make -f Makefile.FreeBSD install |
| 37 | |
Jens Axboe | edffcb9 | 2006-06-08 13:40:18 +0200 | [diff] [blame] | 38 | Likewise with OpenSolaris, use the Makefile.solaris to compile there. |
Jens Axboe | bbfd6b0 | 2006-06-07 19:42:54 +0200 | [diff] [blame] | 39 | This might change in the future if I opt for an autoconf type setup. |
| 40 | |
| 41 | |
Jens Axboe | 972cfd2 | 2006-06-09 11:08:56 +0200 | [diff] [blame] | 42 | Command line |
| 43 | ------------ |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 44 | |
| 45 | $ fio |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 46 | -t <sec> Runtime in seconds |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 47 | -l Generate per-job latency logs |
| 48 | -w Generate per-job bandwidth logs |
Jens Axboe | 9ebc27e | 2006-06-12 10:21:50 +0200 | [diff] [blame] | 49 | -o <file> Log output to file |
Jens Axboe | c6ae0a5 | 2006-06-12 11:04:44 +0200 | [diff] [blame] | 50 | -m Minimal (terse) output |
Jens Axboe | 4785f99 | 2006-05-26 03:59:10 +0200 | [diff] [blame] | 51 | -h Print help info |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 52 | -v Print version information and exit |
| 53 | |
Jens Axboe | 972cfd2 | 2006-06-09 11:08:56 +0200 | [diff] [blame] | 54 | Any parameters following the options will be assumed to be job files. |
| 55 | You can add as many as you want, each job file will be regarded as a |
| 56 | separate group and fio will stonewall it's execution. |
| 57 | |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 58 | |
| 59 | Job file |
| 60 | -------- |
| 61 | |
| 62 | Only a few options can be controlled with command line parameters, |
| 63 | generally it's a lot easier to just write a simple job file to describe |
| 64 | the workload. The job file format is in the ini style format, as it's |
| 65 | easy to read and write for the user. |
| 66 | |
| 67 | The job file parameters are: |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 68 | |
Jens Axboe | 0145205 | 2006-06-07 10:29:47 +0200 | [diff] [blame] | 69 | name=x Use 'x' as the identifier for this job. |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 70 | directory=x Use 'x' as the top level directory for storing files |
Jens Axboe | b50b875 | 2006-10-24 19:05:53 +0200 | [diff] [blame^] | 71 | filename=x Force the use of 'x' as the filename for all files |
| 72 | in this thread. If not given, fio will make up |
| 73 | a suitable filename based on the thread and file |
| 74 | number. |
Jens Axboe | 3d60d1e | 2006-05-25 06:31:06 +0200 | [diff] [blame] | 75 | rw=x 'x' may be: read, randread, write, randwrite, |
| 76 | rw (read-write mix), randrw (read-write random mix) |
Jens Axboe | a6ccc7b | 2006-06-02 10:14:15 +0200 | [diff] [blame] | 77 | rwmixcycle=x Base cycle for switching between read and write |
| 78 | in msecs. |
| 79 | rwmixread=x 'x' percentage of rw mix ios will be reads. If |
| 80 | rwmixwrite is also given, the last of the two will |
| 81 | be used if they don't add up to 100%. |
| 82 | rwmixwrite=x 'x' percentage of rw mix ios will be writes. See |
| 83 | rwmixread. |
Jens Axboe | 9ebc27e | 2006-06-12 10:21:50 +0200 | [diff] [blame] | 84 | rand_repeatable=x The sequence of random io blocks can be repeatable |
| 85 | across runs, if 'x' is 1. |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 86 | size=x Set file size to x bytes (x string can include k/m/g) |
| 87 | ioengine=x 'x' may be: aio/libaio/linuxaio for Linux aio, |
| 88 | posixaio for POSIX aio, sync for regular read/write io, |
Jens Axboe | 8756e4d | 2006-05-27 20:24:53 +0200 | [diff] [blame] | 89 | mmap for mmap'ed io, splice for using splice/vmsplice, |
| 90 | or sgio for direct SG_IO io. The latter only works on |
| 91 | Linux on SCSI (or SCSI-like devices, such as |
| 92 | usb-storage or sata/libata driven) devices. |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 93 | iodepth=x For async io, allow 'x' ios in flight |
| 94 | overwrite=x If 'x', layout a write file first. |
Jens Axboe | 53cdc68 | 2006-10-18 11:50:58 +0200 | [diff] [blame] | 95 | nrfiles=x Spread io load over 'x' number of files per job, |
| 96 | if possible. |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 97 | prio=x Run io at prio X, 0-7 is the kernel allowed range |
| 98 | prioclass=x Run io at prio class X |
| 99 | bs=x Use 'x' for thread blocksize. May include k/m postfix. |
| 100 | bsrange=x-y Mix thread block sizes randomly between x and y. May |
| 101 | also include k/m postfix. |
| 102 | direct=x 1 for direct IO, 0 for buffered IO |
| 103 | thinktime=x "Think" x usec after each io |
| 104 | rate=x Throttle rate to x KiB/sec |
| 105 | ratemin=x Quit if rate of x KiB/sec can't be met |
| 106 | ratecycle=x ratemin averaged over x msecs |
| 107 | cpumask=x Only allow job to run on CPUs defined by mask. |
| 108 | fsync=x If writing, fsync after every x blocks have been written |
| 109 | startdelay=x Start this thread x seconds after startup |
Jens Axboe | 906c8d7 | 2006-06-13 09:37:56 +0200 | [diff] [blame] | 110 | timeout=x Terminate x seconds after startup. Can include a |
| 111 | normal time suffix if not given in seconds, such as |
| 112 | 'm' for minutes, 'h' for hours, and 'd' for days. |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 113 | offset=x Start io at offset x (x string can include k/m/g) |
| 114 | invalidate=x Invalidate page cache for file prior to doing io |
| 115 | sync=x Use sync writes if x and writing |
| 116 | mem=x If x == malloc, use malloc for buffers. If x == shm, |
| 117 | use shm for buffers. If x == mmap, use anon mmap. |
| 118 | exitall When one thread quits, terminate the others |
| 119 | bwavgtime=x Average bandwidth stats over an x msec window. |
| 120 | create_serialize=x If 'x', serialize file creation. |
| 121 | create_fsync=x If 'x', run fsync() after file creation. |
Jens Axboe | f6cbb26 | 2006-10-18 14:16:42 +0200 | [diff] [blame] | 122 | unlink If set, unlink files when done. |
Jens Axboe | fc1a471 | 2006-05-30 13:04:05 +0200 | [diff] [blame] | 123 | end_fsync=x If 'x', run fsync() after end-of-job. |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 124 | loops=x Run the job 'x' number of times. |
| 125 | verify=x If 'x' == md5, use md5 for verifies. If 'x' == crc32, |
| 126 | use crc32 for verifies. md5 is 'safer', but crc32 is |
| 127 | a lot faster. Only makes sense for writing to a file. |
| 128 | stonewall Wait for preceeding jobs to end before running. |
| 129 | numjobs=x Create 'x' similar entries for this job |
| 130 | thread Use pthreads instead of forked jobs |
Jens Axboe | 20dc95c | 2005-12-09 10:29:35 +0100 | [diff] [blame] | 131 | zonesize=x |
| 132 | zoneskip=y Zone options must be paired. If given, the job |
| 133 | will skip y bytes for every x read/written. This |
| 134 | can be used to gauge hard drive speed over the entire |
| 135 | platter, without reading everything. Both x/y can |
| 136 | include k/m/g suffix. |
Jens Axboe | aea47d4 | 2006-05-26 19:27:29 +0200 | [diff] [blame] | 137 | iolog=x Open and read io pattern from file 'x'. The file must |
| 138 | contain one io action per line in the following format: |
| 139 | rw, offset, length |
| 140 | where with rw=0/1 for read/write, and the offset |
| 141 | and length entries being in bytes. |
Jens Axboe | 843a741 | 2006-06-01 21:14:21 -0700 | [diff] [blame] | 142 | write_iolog=x Write an iolog to file 'x' in the same format as iolog. |
| 143 | The iolog options are exclusive, if both given the |
| 144 | read iolog will be performed. |
Jens Axboe | ec94ec5 | 2006-10-20 10:59:19 +0200 | [diff] [blame] | 145 | write_bw_log Write a bandwidth log. |
| 146 | write_lat_log Write a latency log. |
Jens Axboe | c04f7ec | 2006-05-31 10:13:16 +0200 | [diff] [blame] | 147 | lockmem=x Lock down x amount of memory on the machine, to |
| 148 | simulate a machine with less memory available. x can |
| 149 | include k/m/g suffix. |
Jens Axboe | b6f4d88 | 2006-06-02 10:32:51 +0200 | [diff] [blame] | 150 | nice=x Run job at given nice value. |
Jens Axboe | 4e0ba8a | 2006-06-06 09:36:28 +0200 | [diff] [blame] | 151 | exec_prerun=x Run 'x' before job io is begun. |
| 152 | exec_postrun=x Run 'x' after job io has finished. |
Jens Axboe | da86774 | 2006-06-06 10:39:10 -0700 | [diff] [blame] | 153 | ioscheduler=x Use ioscheduler 'x' for this job. |
Jens Axboe | b990b5c | 2006-09-14 09:48:22 +0200 | [diff] [blame] | 154 | cpuload=x For a CPU io thread, percentage of CPU time to attempt |
| 155 | to burn. |
| 156 | cpuchunks=x Split burn cycles into pieces of x. |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 157 | |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 158 | |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 159 | Examples using a job file |
| 160 | ------------------------- |
| 161 | |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 162 | Example 1) Two random readers |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 163 | |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 164 | Lets say we want to simulate two threads reading randomly from a file |
| 165 | each. They will be doing IO in 4KiB chunks, using raw (O_DIRECT) IO. |
| 166 | Since they share most parameters, we'll put those in the [global] |
| 167 | section. Job 1 will use a 128MiB file, job 2 will use a 256MiB file. |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 168 | |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 169 | ; ---snip--- |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 170 | |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 171 | [global] |
| 172 | ioengine=sync ; regular read/write(2), the default |
| 173 | rw=randread |
| 174 | bs=4k |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 175 | direct=1 |
| 176 | |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 177 | [file1] |
| 178 | size=128m |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 179 | |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 180 | [file2] |
| 181 | size=256m |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 182 | |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 183 | ; ---snip--- |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 184 | |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 185 | Generally the [] bracketed name specifies a file name, but the "global" |
| 186 | keyword is reserved for setting options that are inherited by each |
| 187 | subsequent job description. It's possible to have several [global] |
| 188 | sections in the job file, each one adds options that are inherited by |
| 189 | jobs defined below it. The name can also point to a block device, such |
| 190 | as /dev/sda. To run the above job file, simply do: |
| 191 | |
| 192 | $ fio jobfile |
| 193 | |
| 194 | Example 2) Many random writers |
| 195 | |
| 196 | Say we want to exercise the IO subsystem some more. We'll define 64 |
| 197 | threads doing random buffered writes. We'll let each thread use async io |
| 198 | with a depth of 4 ios in flight. A job file would then look like this: |
| 199 | |
| 200 | ; ---snip--- |
| 201 | |
| 202 | [global] |
| 203 | ioengine=libaio |
| 204 | iodepth=4 |
| 205 | rw=randwrite |
| 206 | bs=32k |
| 207 | direct=0 |
| 208 | size=64m |
| 209 | |
| 210 | [files] |
| 211 | numjobs=64 |
| 212 | |
| 213 | ; ---snip--- |
| 214 | |
| 215 | This will create files.[0-63] and perform the random writes to them. |
| 216 | |
| 217 | There are endless ways to define jobs, the examples/ directory contains |
| 218 | a few more examples. |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 219 | |
| 220 | |
| 221 | Interpreting the output |
| 222 | ----------------------- |
| 223 | |
| 224 | fio spits out a lot of output. While running, fio will display the |
| 225 | status of the jobs created. An example of that would be: |
| 226 | |
Jens Axboe | 972cfd2 | 2006-06-09 11:08:56 +0200 | [diff] [blame] | 227 | Threads running: 1: [_r] [24.79% done] [eta 00h:01m:31s] |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 228 | |
| 229 | The characters inside the square brackets denote the current status of |
| 230 | each thread. The possible values (in typical life cycle order) are: |
| 231 | |
| 232 | Idle Run |
| 233 | ---- --- |
| 234 | P Thread setup, but not started. |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 235 | C Thread created. |
| 236 | I Thread initialized, waiting. |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 237 | R Running, doing sequential reads. |
| 238 | r Running, doing random reads. |
| 239 | W Running, doing sequential writes. |
| 240 | w Running, doing random writes. |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 241 | M Running, doing mixed sequential reads/writes. |
| 242 | m Running, doing mixed random reads/writes. |
| 243 | F Running, currently waiting for fsync() |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 244 | V Running, doing verification of written data. |
| 245 | E Thread exited, not reaped by main thread yet. |
| 246 | _ Thread reaped. |
| 247 | |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 248 | The other values are fairly self explanatory - number of threads |
| 249 | currently running and doing io, and the estimated completion percentage |
Jens Axboe | 972cfd2 | 2006-06-09 11:08:56 +0200 | [diff] [blame] | 250 | and time for the running group. It's impossible to estimate runtime |
| 251 | of the following groups (if any). |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 252 | |
| 253 | When fio is done (or interrupted by ctrl-c), it will show the data for |
| 254 | each thread, group of threads, and disks in that order. For each data |
| 255 | direction, the output looks like: |
| 256 | |
| 257 | Client1 (g=0): err= 0: |
| 258 | write: io= 32MiB, bw= 666KiB/s, runt= 50320msec |
| 259 | slat (msec): min= 0, max= 136, avg= 0.03, dev= 1.92 |
| 260 | clat (msec): min= 0, max= 631, avg=48.50, dev=86.82 |
| 261 | bw (KiB/s) : min= 0, max= 1196, per=51.00%, avg=664.02, dev=681.68 |
| 262 | cpu : usr=1.49%, sys=0.25%, ctx=7969 |
| 263 | |
| 264 | The client number is printed, along with the group id and error of that |
| 265 | thread. Below is the io statistics, here for writes. In the order listed, |
| 266 | they denote: |
| 267 | |
| 268 | io= Number of megabytes io performed |
| 269 | bw= Average bandwidth rate |
| 270 | runt= The runtime of that thread |
| 271 | slat= Submission latency (avg being the average, dev being the |
| 272 | standard deviation). This is the time it took to submit |
| 273 | the io. For sync io, the slat is really the completion |
| 274 | latency, since queue/complete is one operation there. |
| 275 | clat= Completion latency. Same names as slat, this denotes the |
| 276 | time from submission to completion of the io pieces. For |
| 277 | sync io, clat will usually be equal (or very close) to 0, |
| 278 | as the time from submit to complete is basically just |
| 279 | CPU time (io has already been done, see slat explanation). |
| 280 | bw= Bandwidth. Same names as the xlat stats, but also includes |
| 281 | an approximate percentage of total aggregate bandwidth |
| 282 | this thread received in this group. This last value is |
| 283 | only really useful if the threads in this group are on the |
| 284 | same disk, since they are then competing for disk access. |
| 285 | cpu= CPU usage. User and system time, along with the number |
| 286 | of context switches this thread went through. |
| 287 | |
| 288 | After each client has been listed, the group statistics are printed. They |
| 289 | will look like this: |
| 290 | |
| 291 | Run status group 0 (all jobs): |
| 292 | READ: io=64MiB, aggrb=22178, minb=11355, maxb=11814, mint=2840msec, maxt=2955msec |
| 293 | WRITE: io=64MiB, aggrb=1302, minb=666, maxb=669, mint=50093msec, maxt=50320msec |
| 294 | |
| 295 | For each data direction, it prints: |
| 296 | |
| 297 | io= Number of megabytes io performed. |
| 298 | aggrb= Aggregate bandwidth of threads in this group. |
| 299 | minb= The minimum average bandwidth a thread saw. |
| 300 | maxb= The maximum average bandwidth a thread saw. |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 301 | mint= The smallest runtime of the threads in that group. |
| 302 | maxt= The longest runtime of the threads in that group. |
Jens Axboe | ebac465 | 2005-12-08 15:25:21 +0100 | [diff] [blame] | 303 | |
| 304 | And finally, the disk statistics are printed. They will look like this: |
| 305 | |
| 306 | Disk stats (read/write): |
| 307 | sda: ios=16398/16511, merge=30/162, ticks=6853/819634, in_queue=826487, util=100.00% |
| 308 | |
| 309 | Each value is printed for both reads and writes, with reads first. The |
| 310 | numbers denote: |
| 311 | |
| 312 | ios= Number of ios performed by all groups. |
| 313 | merge= Number of merges io the io scheduler. |
| 314 | ticks= Number of ticks we kept the disk busy. |
| 315 | io_queue= Total time spent in the disk queue. |
| 316 | util= The disk utilization. A value of 100% means we kept the disk |
| 317 | busy constantly, 50% would be a disk idling half of the time. |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 318 | |
| 319 | |
Jens Axboe | c6ae0a5 | 2006-06-12 11:04:44 +0200 | [diff] [blame] | 320 | Terse output |
| 321 | ------------ |
| 322 | |
| 323 | For scripted usage where you typically want to generate tables or graphs |
| 324 | of the results, fio can output the results in a comma seperated format. |
| 325 | The format is one long line of values, such as: |
| 326 | |
| 327 | client1,0,0,936,331,2894,0,0,0.000000,0.000000,1,170,22.115385,34.290410,16,714,84.252874%,366.500000,566.417819,3496,1237,2894,0,0,0.000000,0.000000,0,246,6.671625,21.436952,0,2534,55.465300%,1406.600000,2008.044216,0.000000%,0.431928%,1109 |
| 328 | |
| 329 | Split up, the format is as follows: |
| 330 | |
| 331 | jobname, groupid, error |
| 332 | READ status: |
| 333 | KiB IO, bandwidth (KiB/sec), runtime (msec) |
| 334 | Submission latency: min, max, mean, deviation |
| 335 | Completion latency: min, max, mean, deviation |
| 336 | Bw: min, max, aggreate percentage of total, mean, deviation |
| 337 | WRITE status: |
| 338 | KiB IO, bandwidth (KiB/sec), runtime (msec) |
| 339 | Submission latency: min, max, mean, deviation |
| 340 | Completion latency: min, max, mean, deviation |
| 341 | Bw: min, max, aggreate percentage of total, mean, deviation |
| 342 | CPU usage: user, system, context switches |
| 343 | |
| 344 | |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 345 | Author |
| 346 | ------ |
| 347 | |
Jens Axboe | aae22ca | 2006-09-05 10:46:22 +0200 | [diff] [blame] | 348 | Fio was written by Jens Axboe <axboe@kernel.dk> to enable flexible testing |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 349 | of the Linux IO subsystem and schedulers. He got tired of writing |
| 350 | specific test applications to simulate a given workload, and found that |
| 351 | the existing io benchmark/test tools out there weren't flexible enough |
| 352 | to do what he wanted. |
| 353 | |
Jens Axboe | aae22ca | 2006-09-05 10:46:22 +0200 | [diff] [blame] | 354 | Jens Axboe <axboe@kernel.dk> 20060905 |
Jens Axboe | 7980911 | 2006-06-09 10:14:54 +0200 | [diff] [blame] | 355 | |