To see what ATTO is writing to the file, we wait until it has completed a write pass, and then cut power to the machine.
I question how reliable this actually is. It might be fine, but I could see it not working as expected (e.g. OS didn’t flush all writes, or reverted something when rolling back the filesystem journal etc).
Regardless, one would think that intercepting the WriteFile call and examining the buffer would be more reliable (or strip theFILE_FLAG_DELETE_ON_CLOSEflag when opening the file).Your point is a good one. Thanks for raising it.
The combination of the observed file contents after several seconds of writing with the behavior difference in all 0s vs all 1s I/O in our fio experiments made me pretty confident about the conclusion we reached, but we should be sure.
To be 100% certain, I just hooked
CreateFileAto remove theFILE_FLAG_DELETE_ON_CLOSE. Examining ATTO’s I/O file after it completes shows that it does indeed contain only 0s.Tomorrow I can also try with ATTO hooked to write all 1s instead of all 0s to observe the performance difference directly in ATTO. (I’m away from the drives that exhibit the performance difference at the moment.)
wtf is 0s i/o actually? can you explained it in lay man terms… so we the average joe people can have a better understanding of what you are trying to tell…
It’s when you write all zeroes to a drive. Some folks do this to securely wipe a drive.
low level format mechanism then? Do this event relevant to our daily dose usage of Storage???
Some folks do this to securely wipe a drive.
Then some smartass controller runs a little RLE on it and then comes the surprise.
Benchmarking can be tricky sometimes, and unfortunately as shown above sometimes manufacturers implement tricks to show better than realistic performance.