X-Git-Url: https://git.kernel.dk/?a=blobdiff_plain;ds=sidebyside;f=fio.1;h=c61948bb52814a2a6bac248c5db0063406225a48;hb=e6590c12f4a8c3f6de2adc9e127b1d2a0585ffae;hp=da44e570167fb16010fed7f6a392b6f3dc241f9f;hpb=ae5888523480f094ce04375a45797e111273ab22;p=fio.git diff --git a/fio.1 b/fio.1 index da44e570..c61948bb 100644 --- a/fio.1 +++ b/fio.1 @@ -182,8 +182,8 @@ set. On Windows, disk devices are accessed as \\.\PhysicalDrive0 for the first device, \\.\PhysicalDrive1 for the second etc. Note: Windows and FreeBSD prevent write access to areas of the disk containing in-use data (e.g. filesystems). If the wanted filename does need to include a colon, then -escape that with a '\' character. For instance, if the filename is -"/dev/dsk/foo@3,0:c", then you would use filename="/dev/dsk/foo@3,0\:c". +escape that with a '\\' character. For instance, if the filename is +"/dev/dsk/foo@3,0:c", then you would use filename="/dev/dsk/foo@3,0\\:c". .TP .BI filename_format \fR=\fPstr If sharing multiple files between jobs, it is usually necessary to have @@ -612,6 +612,17 @@ options. Using Glusterfs libgfapi async interface to direct access to Glusterfs volumes without having to go through FUSE. This ioengine defines engine specific options. +.TP +.B libhdfs +Read and write through Hadoop (HDFS). The \fBfilename\fR option is used to +specify host,port of the hdfs name-node to connect. This engine interprets +offsets a little differently. In HDFS, files once created cannot be modified. +So random writes are not possible. To imitate this, libhdfs engine expects +bunch of small files to be created over HDFS, and engine will randomly pick a +file out of those files based on the offset generated by fio backend. (see the +example job file to create such files, use rw=write option). Please note, you +might want to set necessary environment variables to work with hdfs/libhdfs +properly. .RE .P .RE @@ -657,10 +668,11 @@ Offset in the file to start I/O. Data before the offset will not be touched. .TP .BI offset_increment \fR=\fPint If this is provided, then the real offset becomes the -offset + offset_increment * thread_number, where the thread number is a counter -that starts at 0 and is incremented for each job. This option is useful if -there are several jobs which are intended to operate on a file in parallel in -disjoint segments, with even spacing between the starting points. +offset + offset_increment * thread_number, where the thread number is a +counter that starts at 0 and is incremented for each sub-job (i.e. when +numjobs option is specified). This option is useful if there are several jobs +which are intended to operate on a file in parallel disjoint segments, with +even spacing between the starting points. .TP .BI number_ios \fR=\fPint Fio will normally perform IOs until it has exhausted the size of the region @@ -1191,17 +1203,21 @@ If given, write a bandwidth log of the jobs in this job file. Can be used to store data of the bandwidth of the jobs in their lifetime. The included fio_generate_plots script uses gnuplot to turn these text files into nice graphs. See \fBwrite_lat_log\fR for behaviour of given filename. For this -option, the postfix is _bw.log. +option, the postfix is _bw.x.log, where x is the index of the job (1..N, +where N is the number of jobs) .TP .BI write_lat_log \fR=\fPstr Same as \fBwrite_bw_log\fR, but writes I/O completion latencies. If no -filename is given with this option, the default filename of "jobname_type.log" -is used. Even if the filename is given, fio will still append the type of log. +filename is given with this option, the default filename of +"jobname_type.x.log" is used, where x is the index of the job (1..N, where +N is the number of jobs). Even if the filename is given, fio will still +append the type of log. .TP .BI write_iops_log \fR=\fPstr Same as \fBwrite_bw_log\fR, but writes IOPS. If no filename is given with this -option, the default filename of "jobname_type.log" is used. Even if the -filename is given, fio will still append the type of log. +option, the default filename of "jobname_type.x.log" is used, where x is the +index of the job (1..N, where N is the number of jobs). Even if the filename +is given, fio will still append the type of log. .TP .BI log_avg_msec \fR=\fPint By default, fio will log an entry in the iops, latency, or bw log for every @@ -1214,6 +1230,23 @@ Defaults to 0. If this is set, the iolog options will include the byte offset for the IO entry as well as the other data values. .TP +.BI log_compression \fR=\fPint +If this is set, fio will compress the IO logs as it goes, to keep the memory +footprint lower. When a log reaches the specified size, that chunk is removed +and compressed in the background. Given that IO logs are fairly highly +compressible, this yields a nice memory savings for longer runs. The downside +is that the compression will consume some background CPU cycles, so it may +impact the run. This, however, is also true if the logging ends up consuming +most of the system memory. So pick your poison. The IO logs are saved +normally at the end of a run, by decompressing the chunks and storing them +in the specified log file. This feature depends on the availability of zlib. +.TP +.BI log_store_compressed \fR=\fPbool +If set, and \fBlog\fR_compression is also set, fio will store the log files in +a compressed format. They can be decompressed with fio, using the +\fB\-\-inflate-log\fR command line parameter. The files will be stored with a +\fB\.fz\fR suffix. +.TP .BI disable_lat \fR=\fPbool Disable measurements of total latency numbers. Useful only for cutting back the number of calls to \fBgettimeofday\fR\|(2), as that does impact performance at