Remove .maxval from verify_pattern

Let the parser handle it.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Add verify_pattern option

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Document parser int taking hex input

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Parser: make check_int() accept hex input if prefixed with 0x

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Rename header_offset and header_interval options

Header doesn't really express that this has to do with io verification.
So rename the options to verify_offset and verify_interval.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fix bug in md5 calculation

Commit 8c432325c3df2075a77b27eab8a87704cf7b48ee introduced a bug for
smaller sizes. Just basically revert the optimization, safer to stay
with a 'reference' implementation than skip a memset.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fix md5 verify

The header_interval/offset changes introduced a bug, doing sizeof
on a pointer where it should have been the array. So we didn't compare
the full md5, just the first sizeof(pointer) bytes.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fix header_interval minimum value

It doesn't make sense to have a value of header size or less, since
then there's no room for actual data. Fio even crashes with a value
less than the header size.

Lets just make the minimum twice the header size, seems reasonable...

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Abstract out the data offset calculation

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Cleanup verify pointer casting

Just make 'p' void *, like io_u->buf.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

[PATCH] Offset verification header by a user-specified distance

Offset verification header by user specified distance.

 - Implementation is somewhat simple and probably not ideal but it works. The
   header is just swapped with the bytes at offset after the chunk has been
   filled during populate. Everything is swapped back before verify.

 - Also fixes a bug where we were relying on a moving pointer for increment
   size in populate_verify_io_u (which was working until this patch).

 - Also cleans up a couple smalls things from the header_interval patch.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

[PATCH] Allow verification to be done at finer granularity

Allow verification to be done at a finer granularity than blocksize.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

[PATCH] Fix file_size_high

It is generating a size between

[file_size_low, file_size_low+file_size_high]

where it should be

[file_size_low, file_size_high].

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Show md5 as first verify function

It's probably the best/fastest choice.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Add crc7 and crc64 to HOWTO

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Add sample crc64 checksum

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

[PATCH] Fix fileoffset option

1. The job file we prepared:
----------offset-----------------
[global]
filename=./temp/HOWTO
nrfiles=1
rw=read
size=8K
offset=16k
bs=1k
thread
loops=10
[offset]
description="Option 'offset' doesn't work."
---------------------------------
Besides, we copied the file HOWTO to the directory ./temp/.
So we thought fio would read 8K text sequentially from the point 16K off
the beginning of HOWTO.

we run fio with gdb to see what was read out after the first io, and we
got this:
---------------------------------
... ...
(gdb) bt
from /lib/tls/i686/cmov/libpthread.so.0
(gdb) x/4w io_u->xfer_buf
0x8073f08:      0x6c626154      0x666f2065      0x6e6f6320
0x746e6574
(gdb)
---------------------------------
The above was performed after the first io finished by td_io_queue.
The contents read out as we can see was the ASCII codes for 'Table of
content', which was right from the beginning of file HOWTO.
That means fio read from the beginning but not the point 16K off the
beginning.Is that right?

2. Reason for the problem:
It seems the offset is saved in td->o.start_offset. But it isn't passed
to  f->file_offset.And the setting up of f->io_size doesn't refer to
f->file_offset.

--------------------------------------------------------

And now we can check it with gdb:
--------------------------------------------------------
... ...
(gdb) bt
from /lib/tls/i686/cmov/libpthread.so.0
(gdb) x/4w io_u->xfer_buf
0x8073f08:      0x206b636f      0x7420666f      0x66206568
0x20656c69
(gdb)
---------------------------------------------------------
After the first io, I got '0x206b636f 0x7420666f 0x66206568 0x20656c69'
read out.And they represent the string 'ock of the file '.Then i search
the string in HOWTO and got only one line containing the string:
'norandommap Normally fio will cover every block of the file when doing'
I removed the text following that line in HOWTO, and then I found that
the size of the rest text in HOWTO was 16K, which equaled to the offset
we set in job file.
So I think the option 'offset' does work after the changes.

In fact, I am not sure of the fix, but i do hope it can help.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

[PATCH] Fix size given larger than filesize given

1. The mission is defined like this:
----------filesize----------------
[global]
directory=./temp
nrfiles=2
rw=randread
filesize=32k
size=96k
thread
[filesize]
description="Filesize less than size."
----------------------------------

This job file caused another non-stop thread, which was asked to read
96K but only provided two files of 32K each. The running information
kept looking like this:
---------------------------------
nonggia@nonggia-desktop:~/fio$ fio --version
fio 1.16.9
nonggia@nonggia-desktop:~/fio$ fio filesize
filesize: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=sync, iodepth=1
Starting 1 thread
Jobs: 1 (f=2): [r] [66.7% done] [     0/     0 kb/s] [eta 00m:51s]
---------------------------------

2. The reason:
After having covered both the two files, the thread still had 32K to
issued, while there were already no available files on hand.
I agree that it is far from a bug.Maybe it was the job file that we
should blame. It was wrong written from the beginning.But why not make
it more gentle if we can?

3. Fix suggestion:
So what about change it like this?
Just limit the max td->o.size with the total_size that all the files can
provide.
---------------------------------
diff -Nraup fio-7.25/filesetup.c fio-7.25-filesize/filesetup.c
--- fio-7.25/filesetup.c 2007-07-25 14:25:05.000000000 +0800
+++ fio-7.25-filesize/filesetup.c 2007-07-27 14:17:39.000000000 +0800
@@ -414,7 +414,7 @@ int setup_files(struct thread_data *td)
}
}

- if (!td->o.size)
+ if (!td->o.size || td->o.size > total_size)
td->o.size = total_size;

/*
---------------------------------

Now it behaves like this, just finishes as much job as it can and comes
to the end:
---------------------------------
nonggia@nonggia-desktop:~/fio$ ./filesize_fio filesize
filesize: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=sync, iodepth=1
Starting 1 thread

filesize: (groupid=0, jobs=1): err= 0: pid=8045
  Description  : ["Filesize less than size."]
  read : io=64KiB, bw=32768KiB/s, iops=8000, runt=     2msec
    clat (usec): min=   72, max=  907, avg=167.56, stdev=210.90
  cpu          : usr=0.00%, sys=0.00%, ctx=1
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
>=64=0.0%
     issued r/w: total=16/0, short=0/0
     lat (usec): 100=62.50%, 250=25.00%, 500=6.25%, 1000=6.25%

Run status group 0 (all jobs):
   READ: io=64KiB, aggrb=32768KiB/s, minb=32768KiB/s, maxb=32768KiB/s,
mint=2msec, maxt=2msec

Disk stats (read/write):
  sda: ios=16/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%
nonggia@nonggia-desktop:~/fio$
---------------------------------

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Speed up md5 hash filling/verifying by 20%

Get rid of the on-stack hash copies, hash directly into the buffer.
We need to 'fix' md5 to just initially clear a/b/c/d in md5_update().
Tested, works, generates same checksums.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Clean up verify_io_u()

Use a switch statement, like in the pre-io filler.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Speed up verify fill

It's silly to fill an on-stack header, and then copy it to the io_u.
Just map the pointer to the buffer start.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Type in crc16 verify failure

Should dump crc16, not crc32.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Add crc7 verify type

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Add crc16 verify type

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

[PATCH] Only verify_io_u on reads

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Add data integrity example to netio sample job file

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Missed FIO_UNIDIR io ops flags on net engine

Inadvertenly only set it on the netsplice engine, not net.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

IO verification improvements

- Add a FIO_UNIDIR io ops flag. This like networked IO can't be read/write,
  so verify only makes sense for data summed by another writer.
- Allow a read workload to verify previously written data.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fix verify random bytes filling

Shawn Lewis <shawnlewis@google.com> reports:

---

verify.c: fill_random_bytes() doesn't work as intended.

drand48 on linux returns a double whose value is evenly distributed between
0.0 and 0.1. This is not the same as having an 8-byte value where each bit
has the same chance of being 0 as it does of being 1.

I'd fix this but it should probably be done in a cross-platformish way and
I'm not quite sure how to do it. Maybe just use smaller randoms? Have an
os_random_uint32?

---

I just got rid of os_random_double() and used os_random_long(),
truncating that to an unsigned integer.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

[PATCH] empty result

1. The job file looks like this:
---------runtime------------
[global]
directory=./temp
nrfiles=1
rw=randread
size=32k
thread
[runtime]
description="Too tiny a mission using less than 1sec."
----------------------------

Most of the time,it seems like no io has been performed:
----------------------------
nonggia@nonggia-desktop:~/fio$ fio runtime
runtime: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=sync, iodepth=1
Starting 1 thread

runtime: (groupid=0, jobs=1): err= 0: pid=7155
  Description  : ["Too tiny a mission using less than 1sec."]
  cpu          : usr=0.00%, sys=0.00%, ctx=1
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
>=64=0.0%
     issued r/w: total=8/0, short=0/0
     lat (usec): 100=87.50%, 250=12.50%

Run status group 0 (all jobs):

Disk stats (read/write):
  sda: ios=8/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%
nonggia@nonggia-desktop:~/fio$
----------------------------

2. Reason for the problem:
It is so tiny a job that it may cost less than one second to finish.And
the runtime is rounded down to 0.Just like the io never happened.
We agree that the problem is really trifle, but for testing purpose, we
think it maybe while the fixing.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

[PATCH] non-stop thread

1. The job file causing the problem:
-------------------rw-------------------
[global]
directory=./temp
nrfiles=1
rw=randread:8
norandommap
size=32k
bs=2k
thread
[rw]
description="Offset over real file size."
-----------------------------------------

The job file can keep fio running with the eta increasing and the
progress pausing like this:
----------------------------------------
rw: (g=0): rw=randread, bs=2K-2K/2K-2K, ioengine=sync, iodepth=1
Starting 1 thread
Jobs: 1 (f=1): [r] [92.3% done] [     0/     0 kb/s] [eta 00m:01s]]

----------------------------------------

If we force it to stop, it prints like this:
--------------------------------------------
fio: terminating on signal 2

rw: (groupid=0, jobs=1): err= 0: pid=6124
  Description  : ["Offset over real file size."]
  read : io=28KiB, bw=0KiB/s, iops=0, runt= 61900msec
    clat (usec): min=    5, max=  436, avg=87.79, stdev=123.71
  cpu          : usr=2.01%, sys=93.48%, ctx=13644
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
>=64=0.0%
     issued r/w: total=14/0, short=0/0
     lat (usec): 10=42.86%, 100=35.71%, 250=7.14%, 500=14.29%

Run status group 0 (all jobs):
   READ: io=28KiB, aggrb=0KiB/s, minb=0KiB/s, maxb=0KiB/s,
mint=61900msec, maxt=61900msec

Disk stats (read/write):
  sda: ios=8/45, merge=0/40, ticks=4/368, in_queue=372, util=0.27%
--------------------------------------------
>From above we can see an uncompleted job with a io 28KiB less than what
is specified by 'size'.

2. Reason for problem:
After looking into the source codes,We guess the problem comes from the
function get_next_offset().If the io reaches the end of the file, the
function fails, and the file will be marked as DONE.We wonder if that is
the planned behavior.Isn't it very common to reach the file's end when
doing a random io?

3. Fix suggestion:
Here is the patch:
-----------------------------------------------------
diff -Nraup fio-7.25/io_u.c fio-7.25-rw/io_u.c
--- fio-7.25/io_u.c     2007-07-25 14:25:05.000000000 +0800
+++ fio-7.25-rw/io_u.c 2007-07-26 09:55:22.000000000 +0800
@@ -162,10 +162,12 @@ static int get_next_offset(struct thread
if (get_next_rand_offset(td, f, ddir, &b))
return 1;
} else {
- if (f->last_pos >= f->real_file_size)
- return 1;
-
- b = f->last_pos / td->o.min_bs[ddir];
+ if (f->last_pos >= f->real_file_size) {
+ if (!td_random(td) || get_next_rand_offset(td, f, ddir, &b))
+ return 1;
+ } else {
+ b = f->last_pos / td->o.min_bs[ddir];
+ }
}

io_u->offset = (b * td->o.min_bs[ddir]) + f->file_offset;
------------------------------------------------------

After applying that, we got the job file run to the end normally:
-------------------------------------------------------
nonggia@nonggia-desktop:~/fio$ ./rw_fio rw
rw: (g=0): rw=randread, bs=2K-2K/2K-2K, ioengine=sync, iodepth=1
Starting 1 thread

rw: (groupid=0, jobs=1): err= 0: pid=6519
  Description  : ["Offset over real file size."]
  read : io=32KiB, bw=1560KiB/s, iops=761, runt=    21msec
    clat (usec): min=    5, max=14251, avg=1293.50, stdev=3510.37
  cpu          : usr=0.00%, sys=19.05%, ctx=7
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
>=64=0.0%
     issued r/w: total=16/0, short=0/0
     lat (usec): 10=37.50%, 20=12.50%, 250=12.50%, 750=6.25%, 1000=6.25%
     lat (msec): 2=18.75%, 20=6.25%

Run status group 0 (all jobs):
   READ: io=32KiB, aggrb=1560KiB/s, minb=1560KiB/s, maxb=1560KiB/s,
mint=21msec, maxt=21msec

Disk stats (read/write):
  sda: ios=8/0, merge=0/0, ticks=20/0, in_queue=20, util=13.89%
-------------------------------------------------------

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

[PATCH] Random map block coverage

1. The job file causing the problem:
----------cover-------------------
[global]
directory=./temp
nrfiles=1
rw=randread
size=256K
bsrange=4k-16k
thread
[cover]
description="Not covering every block."
-----------------------------------------

According to HOWTO,the job file will makes fio to cover every block of
the 256k file.But running that, we sometimes got a io gross more than
256k:
----------------------------------------
nonggia@nonggia-desktop:~$ fio --version
fio 1.16.9
nonggia@nonggia-desktop:~/fio$ fio cover
cover: (g=0): rw=randread, bs=4K-16K/4K-4K, ioengine=sync, iodepth=1
Starting 1 thread

cover: (groupid=0, jobs=1): err= 0: pid=6969
  Description  : ["Not covering every block."]
  read : io=264KiB, bw=90112KiB/s, iops=7666, runt=     3msec
    clat (usec): min=   66, max=  438, avg=151.00, stdev=88.90
  cpu          : usr=0.00%, sys=133.33%, ctx=0
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
>=64=0.0%
     issued r/w: total=23/0, short=0/0
     lat (usec): 100=34.78%, 250=56.52%, 500=8.70%

Run status group 0 (all jobs):
   READ: io=264KiB, aggrb=90112KiB/s, minb=90112KiB/s, maxb=90112KiB/s,
mint=3msec, maxt=3msec

Disk stats (read/write):
  sda: ios=49/0, merge=0/0, ticks=4/0, in_queue=4, util=2.86%
--------------------------------------------

It seems fio doesn't cover every block.And using gdb we can see it in
detail:
--------------------------------------------
(gdb) where
from /lib/tls/i686/cmov/libpthread.so.0
(gdb) p td->files[0].num_maps
$1 = 2
(gdb) x/2w td->files[0].file_map
0x8073ff0:      0x00000000      0x00000000
(gdb) finish
Run till exit from #0  do_io (td=0xb7bec000) at fio.c:423
thread_main (data=0xb7bec000) at fio.c:875    0 kb/s] [eta 00m:00s]
875                     clear_state = 1;
(gdb) x/2w td->files[0].file_map
0x8073ff0:      0xffffeffd      0x7ce2df47
(gdb) c
Continuing.
[Thread -1212236896 (LWP 7099) exited]

cover: (groupid=0, jobs=1): err= 0: pid=7098
  Description  : ["Not covering every block."]
  read : io=264KiB, bw=7KiB/s, iops=0, runt= 37522msec
    clat (usec): min=   67, max=  347, avg=143.28, stdev=67.59
    bw (KiB/s) : min=    0, max=    0, per=0.00%, avg= 0.00, stdev= 0.00
  cpu          : usr=0.00%, sys=0.01%, ctx=13
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
>=64=0.0%
     issued r/w: total=29/0, short=0/0
     lat (usec): 100=31.03%, 250=62.07%, 500=6.90%

Run status group 0 (all jobs):
   READ: io=264KiB, aggrb=7KiB/s, minb=7KiB/s, maxb=7KiB/s,
mint=37522msec, maxt=37522msec

Disk stats (read/write):
  sda: ios=50/23, merge=0/32, ticks=0/160, in_queue=160, util=0.13%

Program exited normally.
--------------------------------------------------

2. Reason for problem:
We think when there is no 'norandommap' in the job file, and no ':int'
appended with 'rw',just like the job file above, fio is meant to use
only the blocks not covered yet.
But it seems in the function mark_random_map(), the condition before
calling random_map_free() will never be satisfied.

3. Fix suggestion:
Here is the patch:
-----------------------------------------------------
diff -Nraup fio-7.25/io_u.c fio-7.25-cover/io_u.c
--- fio-7.25/io_u.c     2007-07-25 14:25:05.000000000 +0800
+++ fio-7.25-cover/io_u.c       2007-07-25 20:43:58.000000000 +0800
@@ -55,7 +55,7 @@ static void mark_random_map(struct threa
                 * If we have a mixed random workload, we may
                 * encounter blocks we already did IO to.
                 */
-               if (!td->o.ddir_nr && !random_map_free(td, f, block))
+               if (td->o.ddir_nr==1 && !random_map_free(td, f, block))
                        break;

                idx = RAND_MAP_IDX(td, f, block);
------------------------------------------------------

After that, we check it with gdb:
----------------------------------------------------
(gdb) where
from /lib/tls/i686/cmov/libpthread.so.0
(gdb) p td->files[0].num_maps
$2 = 2
(gdb) x/2w td->files[0].file_map
0x8073ff0:      0x00000000      0x00000000
(gdb) finish
Run till exit from #0  do_io (td=0xb7c48000) at fio.c:423
thread_main (data=0xb7c48000) at fio.c:875    0 kb/s] [eta 00m:00s]
875                     clear_state = 1;
(gdb) x/2w td->files[0].file_map
0x8073ff0:      0xffffffff      0xffffffff
(gdb) c
Continuing.
[Thread -1212073056 (LWP 7443) exited] 5/     0 kb/s] [eta 00m:00s]

cover: (groupid=0, jobs=1): err= 0: pid=7442
  Description  : ["Not covering every block."]
  read : io=256KiB, bw=5KiB/s, iops=0, runt= 46612msec
    clat (usec): min=   62, max=  522, avg=119.50, stdev=88.07
    bw (KiB/s) : min=    0, max=    0, per=0.00%, avg= 0.00, stdev= 0.00
  cpu          : usr=0.00%, sys=0.01%, ctx=11
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%,
>=64=0.0%
     issued r/w: total=38/0, short=0/0
     lat (usec): 100=55.26%, 250=39.47%, 500=2.63%, 750=2.63%

Run status group 0 (all jobs):
   READ: io=256KiB, aggrb=5KiB/s, minb=5KiB/s, maxb=5KiB/s,
mint=46612msec, maxt=46612msec

Disk stats (read/write):
  sda: ios=64/45, merge=0/62, ticks=8/476, in_queue=484, util=0.19%

Program exited normally.
(gdb)
---------------------------------------------------------
Now we can see the expected '0xffffffff 0xffffffff' and the 'io=256KiB'.
By the way, we tested this both on a 32bit machine and a 64bit one.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fix problem with io_u being beyond EOF

Bug report from "ljzhang,Yaxin Hu,Jianchao Tang" <nonggia@sjtu.edu.cn> :

1. The job file causing the problem:
----------ranmap-------------------
[global]
directory=./temp
nrfiles=1
rw=randread
size=64K
bsrange=1k-32k
thread
[ranmap]
description="Over-bounded in mark_random_map()."
-----------------------------------------

Running the job file, we have a high possibility to get a core dump like
this:
----------------------------------------
nonggia@nonggia-desktop:~/fio$ fio --version
fio 1.16.9
nonggia@nonggia-desktop:~/fio$ fio ranmap
ranmap: (g=0): rw=randread, bs=1K-32K/4K-4K, ioengine=sync, iodepth=1
Starting 1 thread
file:io_u.c:64, assert idx < f->num_maps failed
Segmentation fault (core dumped)
nonggia@nonggia-desktop:~/fio$ gdb fio core.6135
... ...
Core was generated by `fio ranmap'.
Program terminated with signal 11, Segmentation fault.
io_u.c:64
64                      fio_assert(td, idx < f->num_maps);
(gdb) bt
io_u.c:64
io_u.c:348
io_u.c:588
from /lib/tls/i686/cmov/libpthread.so.0
(gdb) p io_u->offset
$1 = 41984
(gdb) p io_u->buflen
$2 = 27648
(gdb) p io_u->file->real_file_size
$3 = 65536

2. Reason for the core dump:
The io_u->offset+io_u->buflen was too large to be map in the map file.
They just produced an idx out of the file_map's range.

The fix I produced made sure that get_next_buflen() doesn't go
beyond the real file size, by shrinking the buflen.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

[PATCH] Don't hide pthread_mutex_setpshared in os-linux.h

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fix headers for building with some older libs

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Add ->done variable to force exit when we know we are done

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Only do the root warning once per thread

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Missing carriage return in latency print

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Only warn once for blktrace log open failure

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

One more fio_ddir fixup

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

ddir is of type enum fio_ddir

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Remove gotos from read_iolog_get()

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

IO log fixes

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Add version 2 of the iolog format

The old format had some short comings - notably not supporting > 1
file workloads. So add a new format that defines adding/open/close
of files. Fio will still load the older format iologs, but the new
ones wont work on older fio versions.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fio 1.16.9

Lots of good bug reporting from Erwan Velu, so lets celebrate
those fixes with a new release.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Set minimum value allowed for some options

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fix disk zone test case

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Mention what the [ xxx / xxx kb/s ] means in the status output

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Don't align memory unless using raw io

If it's not raw io, we didn't align the buffer size. So we cannot
align.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Default stdev to 0.0, not -1.0

If we only have a single sample, then the deviation is by definition 0.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fio 1.16.8

1.16.7 was rather short lived, as it had a stupid bug for
the ordinary malloc() backed buffers.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

malloc memory still needs to be aligned, if we are doing direct IO

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Treat option outside of job section as fatal and quit

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fix memory overflow bugs

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fio 1.16.7

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Make a note of Mandriva package availability

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fix bad alignment in buffer size allocation

We typically end up allocating a block more than we need. Usually
not a problem for normal memory, but when we are dealing with
scarce resources such as hugepages, it can be problematic. For many
threads the memory waste could also be a problem.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Add clue for ENOMEM hugepage allocation

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fix typo in shmhuge commit

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Detect and print when the OS doesn't support huge pages

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

git:// url location change

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fio 1.16.6

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fix bug with FIO_IO_U_M/U_NR being transposed

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Guard __must_check ifdef

Some systems seem to pick up the kernel definitions, so check
if __must_check is defined before (potentially) redefining it.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

net engine: cleanup the splice handling

The splice and vmsplice bits were largely duplicated, so abstract
the stuff out so it's clearer to see what is going on.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

net engine: fix listenfd/pipe fd leaks

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

netsplice: use zero-copy if possible

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

netsplice: fix a few typos

It actually works now.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Support for 'netsplice' engine

This IO engine does network transfers, but uses splice() to move data
to/from a socket to a pipe and vmsplice() to move that data to/from
user space.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

guasi engine: remove STFU_GCC()

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fio 1.16.5

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Adaptive io latency distrobution "histogram"

Log ranges all the way down to microseconds, and display the most
appropriate values for those ranges.

This makes the latency usable for sub-milisecond devices as well.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

HOWTO: note that clat/slat can be in micro or mili seconds

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

io_u_mark_depth: just set index, don't fall through

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Cleanup msec <-> usec lat conversion

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

libaio engine: print warning for depth > 1 and buffered IO

Linux aio doesn't support queued buffered IO, it has to be
O_DIRECT. So print a warning to that effect, so that users
of fio don't get bad results by mistake.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Make completion and submission latency use appropriate time base

It's hardcoded as msecs right now, switch the accounting to usecs
and print out the appropriate base determined by the value range.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Add cpus_allowed option

cpumask can be cumbersome to use, since it requires you to calculate
a decimal mask to pass to fio. So add a cpus_allowed option that
takes a text list of allowed cpus, ala: cpus_allowed=1,3,8 will set
the affinity mask for CPUS 1, 3, and 8.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fio 1.16.4

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

HOWTO: expand the cpumask explanation a bit

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Merge branch 'master' of ssh://brick.kernel.dk/data/git/fio

Fix cpu mask setting

Fio passed the mask by value, not by reference. So when
fill_cpu_mask() was done setting the valid CPUs, it was
only on the local value.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Merge branch 'master' of ssh://router/data/git/fio

splice engine: support for vmsplice to user space

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

splice flags are unsigned int, not unsigned long

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Documentation update

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fio 1.16.3

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Tweak meaning of size option

Consider it the full amount of IO to be done, even if the
files used are smaller. Then we'll just restart the workload
until we reach the desired number of bytes.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fix bug with time_based run

We need to clear the FIO_FILE_DONE flag and the number of
files done, to avoid do_io() exiting quickly for a re-run.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fio 1.16.2

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Add comment in os/os-linux.h wrt glibc-2.3.2

It was a broken release wrt cpu affinity, they removed the
size argument from the set/get functions. If you want to
compile on such an ancient glibc, manually define GLIBC_2_3_2.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fix build on older systems

Avoid conflict with MINOR/MAJOR.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fix build/compile for non-blktrace platforms

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

IO verification needs to open and grab a reference to a file

Otherwise it can disappear in midair.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fix bug with random IO and network connections

It isn't a supported configuration.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Update HOWTO on cpumask setting

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Fix cpumask setting/getting on older kernels

Don't call into the affinity functions, unless the user has
specified a mask.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

mmap engine: fix open-for-size check

Don't call into mmap() yet, since we didn't setup ->io_size.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Attempt to work-around possible time warp

A theory - we see gettimeofday() going backwards on some
systems, try and correct for that by just returning 0
for time passed.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>

Improve random pattern without norandommap

Using the random map, random workloads have a natural tendency to
get less random at the end of the run, due to failures to find a
new unused random offset.

Improve the logic to avoid this problem.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>