Arch Linux

portelaux

Member

Registered: 2016-02-16

Posts: 2

IOSTAT report doesn't match with DD benchmark

Hi,

I am running a DD benchmark but the obtained results are not matching with the IOSTAT values.

This is the DD sample:

$ sudo dd bs=4096 count=690 if=/dev/zero of=/mnt/tmp/test oflag=dsync
690+0 records in
690+0 records out
2826240 bytes (2,8 MB) copied, 29,2135 s, 96,7 kB/s

While this benchmark is running, the "iostat -x 1" is reporting on "wkB/s" values between 500 and 600 kB/s.

Something's wrong here.. well, if I don't use the DSYNC, the values are matching.. but I want to do a constant sync for each write operation. Maybe IOSTAT doesn't work well with DSYNC operations ?!

Does anyone know what's the problem here?

Thanks

Last edited by portelaux (2016-02-16 17:05:34)

frostschutz

Member

Registered: 2013-11-15

Posts: 1,647

Re: IOSTAT report doesn't match with DD benchmark

filesystems have overhead and if it syncs every step of the way... depending on what the filesystem does with journal, metadata, etc., who knows.

dd isn't really a benchmark, anyway.

portelaux

Member

Registered: 2016-02-16

Posts: 2

Re: IOSTAT report doesn't match with DD benchmark

Is there anyway to reduce these metadata overheads? I want to benchmark a storage subsystem performance on a writing benchmark without use using the subsystem cache. Do you know another better way?

Anyway, I chose DSYNC because it "does not flush modified metadata unless that metadata is needed in order to allow a subsequent data retrieval to be correctly handled.  For example, changes to st_atime or st_mtime (respectively, time of last access and time of last modification; see stat(2)) do not require flushing because they are not necessary for a subsequent data read to be handled correctly.  On the other hand, a change to the file size (st_size, as made by say ftruncate(2)), would require a metadata flush.". Reading that about DSYNC.. it's seems not reasonable for so much difference between iostat and DD...

So.. I believe this way has the lowest possible overhead.