Sorry to take this thread off topic again, but I received a communication from a friend who read the thread with some information which is pertinent to anyone interested in the off topic part.
I could think of no better place to post this, so apologies to dudeonthebayou for this further interruption.
Following is the information received:
The dd command with the flags fsync
should give a correct result for measuring write speed of the disk.
Alternatively use the option oflag=direct
to achieve reliable results.
The C programme and explanation is very close to being correct ... except this bit ...
The fifth command writes the file to disk
Not so; the write command will move the data to the kernel IO buffers and return. (... giving the appearance of a faster write speed than the drive max write speed ...)
Then the kernel will take on the job to effectively write the data to disk.
The man page of write(2) says the following:
A successful return from write() does not make any guarantee that data has been committed to disk.
In fact, on some buggy implementations, it does not even guarantee that space has successfully been reserved for the data.
The only way to be sure is to call fsync(2) after you are done writing all your data.
The C programme should use the O_SYNC flag on "open" to get the best results.
There is a small difference between the open flag O_SYNC, and calling fsync(fd) before closing the file, O_SYNC will force each "write" to return after the data has been committed, while fsync(fd) will flush the data only when explicitly called, typically before closing the file.
The C test program performs a single write, therefore there will be no difference between using one or the other in this program.
In normal circumstances a change in the content of the data will not affect the write speed - whether all zeroes or not. An exception would be where a compressed filesystem was in play.
The different results obtained are likely due to cache/buffers use.