X-Git-Url: https://git.kernel.dk/?a=blobdiff_plain;ds=sidebyside;f=HOWTO;h=15ee367b57ea1ea4a907d33a7fab77c01c5905b2;hb=443662efa60d9082bc820641e7d1d31dd58d3ae1;hp=569b998f215b78d41a36ac71d78f1506a013af4e;hpb=564ca97254984165e06d5fd4b1270bac95ca55fb;p=fio.git diff --git a/HOWTO b/HOWTO index 569b998f..15ee367b 100644 --- a/HOWTO +++ b/HOWTO @@ -219,6 +219,25 @@ filename=str Fio normally makes up a filename based on the job name, opendir=str Tell fio to recursively add any file it can find in this directory and down the file system tree. +lockfile=str Fio defaults to not doing any locking files before it does + IO to them. If a file or file descriptor is shared, fio + can serialize IO to that file to make the end result + consistent. This is usual for emulating real workloads that + share files. The lock modes are: + + none No locking. The default. + exclusive Only one thread/process may do IO, + excluding all others. + readwrite Read-write locking on the file. Many + readers may access the file at the + same time, but writes get exclusive + access. + + The option may be post-fixed with a lock batch number. If + set, then each thread/process may do that amount of IOs to + the file before giving up the lock. Since lock acqusition is + expensive, batching the lock/unlocks will speed up IO. + readwrite=str rw=str Type of io pattern. Accepted values are: @@ -262,6 +281,10 @@ filesize=siint Individual file sizes. May be a range, in which case fio and limited to 'size' in total (if that is given). If not given, each created file is the same size. +fill_device=bool Sets size to something really large and waits for ENOSPC (no + space left on device) as the terminating condition. Only makes + sense with sequential write. + blocksize=siint bs=siint The block size used for the io units. Defaults to 4k. Values can be given for both read and writes. If a single siint is @@ -313,6 +336,12 @@ bs_unaligned If this option is given, any byte size value within bsrange zero_buffers If this option is given, fio will init the IO buffers to all zeroes. The default is to fill them with random data. +refill_buffers If this option is given, fio will refill the IO buffers + on every submit. The default is to only fill it at init + time and reuse that data. Only makes sense if zero_buffers + isn't specified, naturally. If data verification is enabled, + refill_buffers is also automatically enabled. + nrfiles=int Number of files to use for this job. Defaults to 1. openfiles=int Number of files to keep open at the same time. Defaults to @@ -340,6 +369,8 @@ ioengine=str Defines how the job issues io to the file. The following psync Basic pread(2) or pwrite(2) io. + vsync Basic readv(2) or writev(2) IO. + libaio Linux native asynchronous io. posixaio glibc posix asynchronous io. @@ -377,7 +408,10 @@ ioengine=str Defines how the job issues io to the file. The following cycles according to the cpuload= and cpucycle= options. Setting cpuload=85 will cause that job to do nothing but burn - 85% of the CPU. + 85% of the CPU. In case of SMP machines, + use numjobs= to get desired CPU + usage, as the cpuload only loads a single + CPU at the desired rate. guasi The GUASI IO engine is the Generic Userspace Asyncronous Syscall Interface approach @@ -398,8 +432,9 @@ iodepth=int This defines how many io units to keep in flight against concurrency. iodepth_batch=int This defines how many pieces of IO to submit at once. - It defaults to the same as iodepth, but can be set lower - if one so desires. + It defaults to 1 which means that we submit each IO + as soon as it is available, but can be raised to submit + bigger batches of IO at the time. iodepth_low=int The low water mark indicating when to start filling the queue again. Defaults to the same as iodepth, meaning @@ -425,7 +460,11 @@ fsync=int If writing to a file, issue a sync of the dirty data not sync the file. The exception is the sg io engine, which synchronizes the disk cache anyway. -overwrite=bool If writing to a file, setup the file first and do overwrites. +overwrite=bool If true, writes to a file will always overwrite existing + data. If the file doesn't already exist, it will be + created before the write phase begins. If the file exists + and is large enough for the specified write phase, nothing + will be done. end_fsync=bool If true, fsync file contents when the job exits. @@ -433,10 +472,6 @@ fsync_on_close=bool If true, fio will fsync() a dirty file on close. This differs from end_fsync in that it will happen on every file close, not just at the end of the job. -rwmixcycle=int Value in milliseconds describing how often to switch between - reads and writes for a mixed workload. The default is - 500 msecs. - rwmixread=int How large a percentage of the mix should be reads. rwmixwrite=int How large a percentage of the mix should be writes. If both @@ -453,6 +488,12 @@ norandommap Normally fio will cover every block of the file when doing fio doesn't track potential block rewrites which may alter the calculated checksum for that block. +softrandommap See norandommap. If fio runs with the random block map enabled + and it fails to allocate the map, if this option is set it + will continue without a random block map. As coverage will + not be as complete as with random maps, this option is + disabled by default. + nice=int Run the job with the given nice value. See man nice(2). prio=int Set the io priority value of this job. Linux limits us to @@ -625,15 +666,6 @@ verify=str If writing to a file, fio can verify the file contents (timestamp, block number etc.). The block number is verified. - pattern Fill the IO buffers with a specific pattern, - that we can use to verify. Depending on the - width of the pattern, fio will fill 1/2/3/4 - bytes of the buffer at the time. The pattern - cannot be larger than a 32-bit quantity. The - given pattern is given as a postfix to this - option, ala: verify=pattern:0x5a. It accepts - both hex and dec values. - null Only pretend to verify. Useful for testing internals with ioengine=null, not for much else. @@ -659,6 +691,14 @@ verify_interval=siint Write the verification header at a finer granularity size of header_interval. blocksize should divide this evenly. +verify_pattern=int If set, fio will fill the io buffers with this + pattern. Fio defaults to filling with totally random + bytes, but sometimes it's interesting to fill with a known + pattern for io verification purposes. Depending on the + width of the pattern, fio will fill 1/2/3/4 bytes of the + buffer at the time. The verify_pattern cannot be larger than + a 32-bit quantity. + verify_fatal=bool Normally fio will keep checking the entire contents before quitting on a block verification failure. If this option is set, fio will exit the job on the first observed @@ -784,6 +824,8 @@ Client1 (g=0): err= 0: bw (KiB/s) : min= 0, max= 1196, per=51.00%, avg=664.02, stdev=681.68 cpu : usr=1.49%, sys=0.25%, ctx=7969, majf=0, minf=17 IO depths : 1=0.1%, 2=0.3%, 4=0.5%, 8=99.0%, 16=0.0%, 32=0.0%, >32=0.0% + submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% + complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% issued r/w: total=0/32768, short=0/0 lat (msec): 2=1.6%, 4=0.0%, 10=3.2%, 20=12.8%, 50=38.4%, 100=24.8%, lat (msec): 250=15.2%, 500=0.0%, 750=0.0%, 1000=0.0%, >=2048=0.0% @@ -821,6 +863,11 @@ IO depths= The distribution of io depths over the job life time. The 16= entries includes depths up to that value but higher than the previous entry. In other words, it covers the range from 16 to 31. +IO submit= How many pieces of IO were submitting in a single submit + call. Each entry denotes that amount and below, until + the previous entry - eg, 8=100% mean that we submitted + anywhere in between 5-8 ios per submit call. +IO complete= Like the above submit number, but for completions instead. IO issued= The number of read/write requests issued, and how many of them were short. IO latencies= The distribution of IO completion latencies. This is the