if (!quiet) {
                    print_size(ret_size);
                    printf(" %s %s (%s %s", write_test ? ">>>" : "<<<",
                                    path, fstype, device);
                    if (device_size)
                            print_size(device_size);
                    time_t t = time(NULL);
                    struct tm tm = *gmtime(&t);
                    printf(": %d-%d-%d %d:%d:%d", tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec);
                    printf("): request=%lu time=", (long unsigned)request);
                    print_time(this_time);
                    if (request == 1) {
                            printf(" (warmup)");
                    } else if (this_time < min_valid_time) {
                            printf(" (too fast)");
                    } else if (this_time > max_valid_time) {
                            printf(" (too slow)");
                    } else if (part.valid > 5 && part.min < part.max) {
                            int percent = (this_time - part.min) * 100 /
                                            (part.max - part.min);
                            if (percent < 5)
                                    printf(" (fast)");
                            else if (percent > 95)
                                    printf(" (slow)");
                    }
                    printf("\n");
            }

What steps will reproduce the problem?
1. run make

What is the expected output? What do you see instead?
Program should compile

What version of the product are you using? On what operating system?
ioping-0.4 on FreeBSD 8.1-RELEASE

Please provide any additional information below.
#make
Unknown modifier '/'

Unknown modifier '/'

cc -O2 -pipe  -std=c99 -g -Wall -Wextra -pedantic -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -c ioping.c
In file included from ioping.c:26:
/usr/include/malloc.h:3:2: error: #error "<malloc.h> has been replaced by 
<stdlib.h>"
ioping.c: In function 'main':
ioping.c:355: error: 'BLKGETSIZE64' undeclared (first use in this function)
ioping.c:355: error: (Each undeclared identifier is reported only once
ioping.c:355: error: for each function it appears in.)
ioping.c:375: warning: implicit declaration of function 'memalign'
ioping.c:375: warning: assignment makes pointer from integer without a cast
ioping.c:413: warning: implicit declaration of function 'posix_fadvise'
ioping.c:413: error: 'POSIX_FADV_RANDOM' undeclared (first use in this function)
ioping.c:442: error: 'POSIX_FADV_DONTNEED' undeclared (first use in this 
function)
*** Error code 1

Original issue reported on code.google.com by [email protected] on 8 Jun 2011 at 1:41

What steps will reproduce the problem?
1. ioping -c 10 -s 16K /dev/mapper/mpath256
What is the expected output? What do you see instead?

we expected io should happen for 16k on the device (RAW LUN)

Actual Result:

IO's are written on RAW LUNs are 4kb block size.

What version of the product are you using? On what operating system?
[root@DC2-RHEL58-MPIO ~]# ioping -v
ioping 0.6
[root@DC2-RHEL58-MPIO ~]#

OS system: RHEL 5.8


Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 4 Jan 2013 at 5:24

This PR adds the option -N to ioping to allow it output statistics in a netdata friendly format. The fping and netdata interaction was organized in the same way a long time ago. A corresponding PR was made for netdata.

Compilation of ioping v0.7 is broken under FreeBSD with follow error:

--
ioping.c:579:17: warning: implicit declaration of function 'fdatasync' is 
invalid in C99 [-Wimplicit-function-declaration]
        if (!cached && fdatasync(fd) < 0)
                       ^
2 warnings generated.
/tmp/ioping-QYo1BH.o: In function `do_pwrite':
ioping.c:(.text+0xb16): undefined reference to `fdatasync'
--

cause there no fdatasync functions. fsync(2) must be used instead.


Also, CLANG out the warning about incompatible format for VERSION variable:

--
ioping.c:225:33: warning: format specifies type 'char *' but the argument has 
type 'double' [-Wformat]
        fprintf(stderr, "ioping %s\n", VERSION);
                                ~~     ^~~~~~~
                                %f
<command line>:1:17: note: expanded from here
#define VERSION 0.7
                ^~~
--


Ive don't know what is correct solution to fix this:

-- fprintf(stderr, "ioping %f\n", VERSION);
++ fprintf(stderr, "ioping %f\n", VERSION);

or

-- #define VERSION 0.7
++ #define VERSION "0.7"

or  (char *)VERSION

Temporary ive apply %f type for fprintf.

Please review attached patch.

Original issue reported on code.google.com by [email protected] on 23 Jul 2013 at 12:18

Attachments:

• patch-ioping.c

I'm experiencing strange behavior when running ioping and using the blkio 
cgroup controller to throttle IOPs. ioping is producing the expected output 
according to what I throttle IOPs at, but it 'hangs' before returning the 
results. I do not see this behavior when not using blkio to throttle IOPs -- 
results are returned much more quickly, as expected.

I am running OpenVZ containers with the latest RHEL6 OpenVZ kernel.

For example, if I run `./ioping -RL .` with IOPs throttled to 150/sec, there is 
a 'pause' for 110 seconds (the length of the pause is pretty consistent), and 
then the results get outputted:

--- . (simfs /vz/private/101) ioping statistics ---
451 requests completed in 3008.0 ms, 153 iops, 38.2 mb/s
min/avg/max/mdev = 1.3/6.5/72.5/15.8 ms

Any thoughts as to why this is happening? I'm trying to determine if this has 
to do with the way ioping is coded, or if it's some sort of anomaly with the 
blkio controller itself.

Original issue reported on code.google.com by [email protected] on 22 Oct 2011 at 12:16

I get a overflow warning when building ioping with gcc 9.2.0 on Linux

gcc -o ioping ioping.c -Os -fomit-frame-pointer -std=gnu99 -Wall -Wextra -pedantic -Wl,--as-needed -lm -lrt
ioping.c: In function 'get_device_size':                           
ioping.c:828:18: warning: overflow in conversion from 'long unsigned int' to 'int' changes value from '2148012658' to '-2146954638' [-Woverflow]
  828 |  ret = ioctl(fd, BLKGETSIZE64, &blksize);                             
      |                  ^~~~~~~~~~~~       

Several enhancements for Makefile:

* Drop -g from default CFLAGS, as debugging build shouldn't be the default build
* exchange LDFLAGS with LIBS, LDFLAGS should only contain linker directives, 
where as LIBS contain the libs to be linked with
* Let PREFIX to be easily overwriten

All those changes are necessary for packing ioping easily for distributions.

Please include

Original issue reported on code.google.com by [email protected] on 13 Jan 2012 at 8:10

Attachments:

• ioping-0.6-makefile.patch

What steps will reproduce the problem?
1. Untar 
2. Run make

What is the expected output? What do you see instead?
Program should compile


What version of the product are you using? On what operating system?
ioping-0.4 on Mac OS X 10.6.7

Please provide any additional information below.

make
cc -std=c99 -g -Wall -Wextra -pedantic -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -c 
-o ioping.o ioping.c
ioping.c:26:20: error: malloc.h: No such file or directory
ioping.c: In function ‘parse_device’:
ioping.c:271: warning: implicit declaration of function ‘getline’
ioping.c: In function ‘main’:
ioping.c:338: error: ‘O_DIRECT’ undeclared (first use in this function)
ioping.c:338: error: (Each undeclared identifier is reported only once
ioping.c:338: error: for each function it appears in.)
ioping.c:355: error: ‘BLKGETSIZE64’ undeclared (first use in this function)
ioping.c:375: warning: implicit declaration of function ‘memalign’
ioping.c:375: warning: assignment makes pointer from integer without a cast
ioping.c:413: warning: implicit declaration of function ‘posix_fadvise’
ioping.c:413: error: ‘POSIX_FADV_RANDOM’ undeclared (first use in this 
function)
ioping.c:442: error: ‘POSIX_FADV_DONTNEED’ undeclared (first use in this 
function)
make: *** [ioping.o] Error 1

Original issue reported on code.google.com by [email protected] on 6 Jun 2011 at 4:05

The raw statistics are printed in ns, and not in us. At least since some 0.9 versions.

I have tested this on 2 Debian versions and with the latest git source:

Debian jessie (8): (correct output in usec)

$ ioping -v
ioping 0.9

$ ioping -i 1 -p 5 -W /tmp/
4 KiB to /tmp/ (ext4 /dev/mapper/vg0-tmp): request=1 time=151 us
4 KiB to /tmp/ (ext4 /dev/mapper/vg0-tmp): request=2 time=141 us
4 KiB to /tmp/ (ext4 /dev/mapper/vg0-tmp): request=3 time=138 us
4 KiB to /tmp/ (ext4 /dev/mapper/vg0-tmp): request=4 time=143 us
4 KiB to /tmp/ (ext4 /dev/mapper/vg0-tmp): request=5 time=175 us
5 748 6684 27379679 138 150 175 13
^C
--- /tmp/ (ext4 /dev/mapper/vg0-tmp) ioping statistics ---
5 requests completed in 4.86 s, 6.68 k iops, 26.1 MiB/s
min/avg/max/mdev = 138 us / 149 us / 175 us / 13 us

Debian stretch (9): (incorrect output, manpage says usec for raw output)

$ ioping -v
ioping 0.9

$ ioping -i 1 -p 5 -W /tmp/
4 KiB >>> /tmp/ (ext4 /dev/sda2): request=1 time=4.89 ms (warmup)
4 KiB >>> /tmp/ (ext4 /dev/sda2): request=2 time=2.31 ms
4 KiB >>> /tmp/ (ext4 /dev/sda2): request=3 time=9.09 ms
4 KiB >>> /tmp/ (ext4 /dev/sda2): request=4 time=1.97 ms
4 KiB >>> /tmp/ (ext4 /dev/sda2): request=5 time=2.67 ms
4 16033870 249 1021837 1972563 4008468 9088666 2943301 5 4002766704
^C
--- /tmp/ (ext4 /dev/sda2) ioping statistics ---
4 requests completed in 16.0 ms, 16 KiB written, 249 iops, 997.9 KiB/s
generated 5 requests in 4.44 s, 20 KiB, 1 iops, 4.51 KiB/s
min/avg/max/mdev = 1.97 ms / 4.01 ms / 9.09 ms / 2.94 ms

Latest git: (output in ns, but documentation says usec)

$ ./ioping -v
ioping 1.0.12.g5bd3232

$ ./ioping -i 1 -p 5 -W /tmp/
4 KiB >>> /tmp/ (ext4 /dev/dm-1): request=1 time=163.9 us (warmup)
4 KiB >>> /tmp/ (ext4 /dev/dm-1): request=2 time=135.3 us
4 KiB >>> /tmp/ (ext4 /dev/dm-1): request=3 time=106.2 us
4 KiB >>> /tmp/ (ext4 /dev/dm-1): request=4 time=111.7 us
4 KiB >>> /tmp/ (ext4 /dev/dm-1): request=5 time=128.1 us
4 481326 8310 34039300 106209 120332 135300 11808 5 4000234525
^C
--- /tmp/ (ext4 /dev/dm-1) ioping statistics ---
4 requests completed in 481.3 us, 16 KiB written, 8.31 k iops, 32.5 MiB/s
generated 5 requests in 4.51 s, 20 KiB, 1 iops, 4.44 KiB/s
min/avg/max/mdev = 106.2 us / 120.3 us / 135.3 us / 11.8 us

What steps will reproduce the problem?
1. ioping . -s 4G (actually starting from 2G)


What is the expected output? What do you see instead?

I expect normal workflow, instead I get:
ioping: write failed: Success

What version of the product are you using? On what operating system?

Centos 7.1
3.10.0-123.20.1.el7.x86_64
ioping 0.8

Please provide any additional information below.
At least the output does not lead to anywhere near problem. I have about 20Gig 
free, and it fails to write 2147479552. I use xfs here, and the limit is: 
Maximum File Size = 9 Million TB = 9 ExaB. It may be a problem on my system, 
yet the message given is unclear.

An excerpt from strace:
open("./ioping.jIXgE6", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
unlink("./ioping.jIXgE6")               = 0
pwrite(3, "********************************"..., 4294967296, 0) = 2147479552
write(2, "ioping: ", 8ioping: )                 = 8
write(2, "write failed", 12write failed)            = 12
write(2, ": ", 2: )                       = 2
write(2, "Success\n", 8Success
)                = 8

Original issue reported on code.google.com by [email protected] on 25 Mar 2015 at 5:06

Hi, as I have to test the network between a customers hypervisor and the storage system, I implemented a very basic support for failed requests. Would be great to have this merged. Br Willi

Hi, I have added support for ppc64le build on travis-ci in the branch . The travis-ci build log can be tracked on the link :https://travis-ci.com/github/sanjaymsh/ioping/builds/191023067 . I believe it is ready for the final review and merge. Please have a look on it.

Thanks !!

While working for a client with a flaky storage system we needed to store ioping statistics in a database for easy graph generation, so I added some basic SQLite3 support. My mileage with C is limited so it's not pretty, but it worked well enough for us.