By user12625760 on Jun 18, 2009
I'm pleased to announce the Diskomizer test suite has been open sourced. Diskomizer started life in the dark days before ZFS when we lived in a world full1 of bit flips, phantom writes, phantom reads, misplaced writes and misplaced reads.
With a storage architecture that does not use end to end data verification the best that you can hope for was that your application will spot errors quickly and allow you to diagnose the broken part or bug quickly. Diskomizer was written to be a “simple” application that could verify all the data paths worked correctly and worked correctly under extreme load. It has been and is used by support, development and test groups for system verification.
For more details of what Diskomizer is and how to build and install read these pages:
You can download the source and precompiled binaries from:
and can browse the source here:
First remember in most cases Diskomizer will destroy all the data on any target you point it at. So extreme care is advised.
I will say that again.
Diskomizer will destroy all the data on any target that you point it at.
For the purposes of this explanation I am going to use ZFS volumes so that I can create and destroy them with confidence that I will not be destroying someone's data.
First lets create some volumes.
# i=0 # while (( i < 10 )) do zfs create -V 10G storage/chris/testvol$i let i=i+1 done #
Now write the names of the devices you wish to test into a file after the key “DEVICE=”:
# echo DEVICE= /dev/zvol/rdsk/storage/chris/testvol\* > test_opts
Now start the test. When you installed diskomizer it put the standard option files on the system and has a search path so that it can find them. I'm using the options file “background” which will make the test go into the back ground redirecting the output into a file called “stdout” and any errors into a file called “stderr”:
# /opt/SUNWstc-diskomizer/bin/diskomizer -f test_opts -f background #
If Diskomizer has any problems with the configuration it will report them and exit. This is to minimize the risk to your data from a typo. Also the default is to open devices and files exclusively to again reduce the danger to your data (and to reduce false positives where it detects data corruption).
Once up and running it will report it's progress for each process in the output file:
# tail -5 stdout PID 1152: INFO /dev/zvol/rdsk/storage/chris/testvol7 (zvol0:a)2 write times (0.000,0.049,6.068) 100% PID 1152: INFO /dev/zvol/rdsk/storage/chris/testvol1 (zvol0:a) write times (0.000,0.027,6.240) 100% PID 1152: INFO /dev/zvol/rdsk/storage/chris/testvol7 (zvol0:a) read times (0.000,1.593,6.918) 100% PID 1154: INFO /dev/zvol/rdsk/storage/chris/testvol9 (zvol0:a) write times (0.000,0.070,6.158) 79% PID 1151: INFO /dev/zvol/rdsk/storage/chris/testvol0 (zvol0:a) read times (0.000,0.976,7.523) 100% #
meanwhile all the usual tools can be used to view the IO:
# zpool iostat 5 5 capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- storage 460G 15.9T 832 4.28K 6.49M 31.2M storage 460G 15.9T 3.22K 9.86K 25.8M 77.2M storage 460G 15.9T 3.77K 6.04K 30.1M 46.8M storage 460G 15.9T 2.90K 11.7K 23.2M 91.4M storage 460G 15.9T 3.63K 5.86K 29.1M 45.7M #
1Full may be an exaggeration but we will never know thanks to the fact that the data loss was silent. There were enough cases reported where there was reason to doubt whether the data was good to keep me busy.