X-Git-Url: https://git.kernel.dk/?p=fio.git;a=blobdiff_plain;f=HOWTO;h=6e052f532a0963c0d3710bb626f59696d60e2f9b;hp=6d80360574e0c89899756cbc6a1d9838293c9c81;hb=bb7816439c44f6f98debd8afd167da14d612574c;hpb=e6989e10964f5ae30e0ba8f0cd27a663baf5617b diff --git a/HOWTO b/HOWTO index 6d803605..6e052f53 100644 --- a/HOWTO +++ b/HOWTO @@ -10,6 +10,9 @@ Table of contents 7. Terse output 8. Trace file format 9. CPU idleness profiling +10. Verification and triggers +11. Log File Formats + 1.0 Overview and history ------------------------ @@ -962,6 +965,8 @@ random_distribution=str:float By default, fio will use a completely uniform random Uniform random distribution zipf Zipf distribution pareto Pareto distribution + gauss Normal (guassian) distribution + zoned Zoned random distribution When using a zipf or pareto distribution, an input value is also needed to define the access pattern. For zipf, this @@ -970,7 +975,28 @@ random_distribution=str:float By default, fio will use a completely uniform what the given input values will yield in terms of hit rates. If you wanted to use zipf with a theta of 1.2, you would use random_distribution=zipf:1.2 as the option. If a non-uniform - model is used, fio will disable use of the random map. + model is used, fio will disable use of the random map. For + the gauss distribution, a normal deviation is supplied as + a value between 0 and 100. + + For a zoned distribution, fio supports specifying percentages + of IO access that should fall within what range of the file or + device. For example, given a criteria of: + + 60% of accesses should be to the first 10% + 30% of accesses should be to the next 20% + 8% of accesses should be to to the next 30% + 2% of accesses should be to the next 40% + + we can define that through zoning of the random accesses. For + the above example, the user would do: + + random_distribution=zoned:60/10:30/20:8/30:2/40 + + similarly to how bssplit works for setting ranges and + percentages of block sizes. Like bssplit, it's possible to + specify separate zones for reads, writes, and trims. If just + one set is given, it'll apply to all of them. percentage_random=int For a random workload, set how big a percentage should be random. This defaults to 100%, in which case the workload @@ -1540,7 +1566,7 @@ write_bw_log=str If given, write a bandwidth log of the jobs in this job filename. For this option, the suffix is _bw.x.log, where x is the index of the job (1..N, where N is the number of jobs). If 'per_job_logs' is false, then the filename will not - include the job index. + include the job index. See 'Log File Formats'. write_lat_log=str Same as write_bw_log, except that this option stores io submission, completion, and total latencies instead. If no @@ -1554,8 +1580,8 @@ write_lat_log=str Same as write_bw_log, except that this option stores io and foo_lat.x.log, where x is the index of the job (1..N, where N is the number of jobs). This helps fio_generate_plot fine the logs automatically. If 'per_job_logs' is false, then - the filename will not include the job index. - + the filename will not include the job index. See 'Log File + Formats'. write_iops_log=str Same as write_bw_log, but writes IOPS. If no filename is given with this option, the default filename of @@ -1563,7 +1589,7 @@ write_iops_log=str Same as write_bw_log, but writes IOPS. If no filename is (1..N, where N is the number of jobs). Even if the filename is given, fio will still append the type of log. If 'per_job_logs' is false, then the filename will not include - the job index. + the job index. See 'Log File Formats'. log_avg_msec=int By default, fio will log an entry in the iops, latency, or bw log for every IO that completes. When writing to the @@ -1783,6 +1809,9 @@ that defines them is selected. enabled when polling for a minimum of 0 events (eg when iodepth_batch_complete=0). +[psyncv2] hipri Set RWF_HIPRI on IO, indicating to the kernel that + it's of higher priority than normal. + [cpu] cpuload=int Attempt to use the specified percentage of CPU cycles. [cpu] cpuchunks=int Split the load into cycles of the given time. In @@ -1958,7 +1987,9 @@ runt= The runtime of that thread cpu= CPU usage. User and system time, along with the number of context switches this thread went through, usage of system and user time, and finally the number of major - and minor page faults. + and minor page faults. The CPU utilization numbers are + averages for the jobs in that reporting group, while the + context and fault counters are summed. IO depths= The distribution of io depths over the job life time. The numbers are divided into powers of 2, so for example the 16= entries includes depths up to that value but higher @@ -2219,10 +2250,43 @@ localbox$ fio --client=server --trigger-file=/tmp/my-trigger --trigger="ipmi-reb For this case, fio would wait for the server to send us the write state, then execute 'ipmi-reboot server' when that happened. -10.1 Loading verify state +10.2 Loading verify state ------------------------- To load store write state, read verification job file must contain the verify_state_load option. If that is set, fio will load the previously stored state. For a local fio run this is done by loading the files directly, and on a client/server run, the server backend will ask the client to send the files over and load them from there. + + +11.0 Log File Formats +--------------------- + +Fio supports a variety of log file formats, for logging latencies, bandwidth, +and IOPS. The logs share a common format, which looks like this: + +time (msec), value, data direction, offset + +Time for the log entry is always in milliseconds. The value logged depends +on the type of log, it will be one of the following: + + Latency log Value is latency in usecs + Bandwidth log Value is in KB/sec + IOPS log Value is IOPS + +Data direction is one of the following: + + 0 IO is a READ + 1 IO is a WRITE + 2 IO is a TRIM + +The offset is the offset, in bytes, from the start of the file, for that +particular IO. The logging of the offset can be toggled with 'log_offset'. + +If windowed logging is enabled though 'log_avg_msec', then fio doesn't log +individual IOs. Instead of logs the average values over the specified +period of time. Since 'data direction' and 'offset' are per-IO values, +they aren't applicable if windowed logging is enabled. If windowed logging +is enabled and 'log_max_value' is set, then fio logs maximum values in +that window instead of averages. +