TL;DR Version
When using badblocks in write-mode, I found a block size of 4096 and the number of blocks tested of 4096 or greater to give me the best throughput using an HP Micro Sevrer.
Warning: This will destroy anything that is currently on your HDD
In-Depth Version
I have started using badblocks to break in and test new HDDs and test and wipe drives I am repurposing. With 2TB+ drives this process can take quite a while for each pass of the destructive write-mode test (-w) which writes and verifies a pattern on each block of the drive. I did some testing to see what block count to test at a time gives the highest throughput at a constant block size. All these tests were done using the first 4GiB of a Seagate ST3000DM001 to limit testing time, but this means the results are a ceiling for whole drive throughput. The drive is in an HP N40L with 4GB of ram and Ubuntu server 12.04.1 LTS.
Throughput measurement was taking using iotop in batch mode at 1s intervals.
The output of iotop, even in batch mode, is not great for analysis, but a little vim-foo and opening the output as a CSV gets the data into Excel.
I settled on a 100% arbitrary fixed number for block size (-b) of 4096 bytes, default is 1024 bytes. I started testing with the number of blocks tested at a time (-c) at double the default of 64.
The data are average instantaneous throughputs. I used the first three passes (0xaa, 0x55, 0xff) for each test_value and calculated an average instantaneous throughput for each pass. I then averaged the throughput of the three passes to get the values in the table. I should apologize to any statisticians reading this and screaming at your monitors...
badblocks Results
I wanted something to compare my throughput results to, so I ran read and write tests using DD using direct IO, a block size equal to 4096*test_value, and a count to limit me to 4GiB/4.3GB. I used direct IO because badblocks has a flag to force buffered IO. If anyone knows for sure if badblocks uses direct IO, let me know. Otherwise, I will look at badblocks code later to verify.
DD Results
The DD tests give me some wildly varying read values and write values that increase. After comparing both data sets, I find badblocks decrease in read throughput as block count increases interesting. Badblocks first writes to the disk and when done goes back and reads from the entire disk verifying the data. I am guessing it is a limitation of how they are checking the blocks, I will have to look at the code to see if I can find anything.
So, if you use badblocks -wb 4096 use at least -c 4096 to get highest throughput with the HP micro server.
When using badblocks in write-mode, I found a block size of 4096 and the number of blocks tested of 4096 or greater to give me the best throughput using an HP Micro Sevrer.
Warning: This will destroy anything that is currently on your HDD
Code:
root@server:~# badblocks /dev/sdX -wsb 4096 -c 4096
I have started using badblocks to break in and test new HDDs and test and wipe drives I am repurposing. With 2TB+ drives this process can take quite a while for each pass of the destructive write-mode test (-w) which writes and verifies a pattern on each block of the drive. I did some testing to see what block count to test at a time gives the highest throughput at a constant block size. All these tests were done using the first 4GiB of a Seagate ST3000DM001 to limit testing time, but this means the results are a ceiling for whole drive throughput. The drive is in an HP N40L with 4GB of ram and Ubuntu server 12.04.1 LTS.
Throughput measurement was taking using iotop in batch mode at 1s intervals.
Code:
root@server:~# iotop -bou root | grep -e /dev/sdX > test_value.out
I settled on a 100% arbitrary fixed number for block size (-b) of 4096 bytes, default is 1024 bytes. I started testing with the number of blocks tested at a time (-c) at double the default of 64.
Code:
root@server:~# time badblocks /dev/sdX -swb 4096 -c test_value 1048576 0
badblocks Results
Test Value | Avg. Read (MB/s) | Avg. Write (MB/s) | Combined Avg. (MB/s) | Test Duration Wall Time MM:SS.SS |
128 | 174.20 | 44.98 | 109.59 | 7:43.77 |
256 | 178.03 | 71.95 | 124.99 | 5:19.96 |
512 | 179.08 | 102.72 | 140.90 | 4:11.29 |
1024 | 177.53 | 130.48 | 154.00 | 3:37.72 |
2048 | 152.62 | 151.14 | 151.88 | 3:36.10 |
4096 | 157.48 | 164.17 | 160.82 | 3:23.97 |
8192 | 159.10 | 171.00 | 165.05 | 3:19.82 |
16384 | 159.57 | 174.64 | 167.10 | 3:16.81 |
32768 | 160.98 | 176.41 | 168.70 | 3:15.88 |
I wanted something to compare my throughput results to, so I ran read and write tests using DD using direct IO, a block size equal to 4096*test_value, and a count to limit me to 4GiB/4.3GB. I used direct IO because badblocks has a flag to force buffered IO. If anyone knows for sure if badblocks uses direct IO, let me know. Otherwise, I will look at badblocks code later to verify.
DD Results
Test Value | DD Read (MB/s) | DD Write (MB/s) |
128 | 188 | 47.0 |
256 | 188 | 75.1 |
512 | 188 | 107 |
1024 | 188 | 136 |
2048 | 187 | 157 |
4096 | 188 | 160 |
8192 | 188 | 167 |
16384 | 187 | 170 |
32768 | 187 | 172 |
The DD tests give me some wildly varying read values and write values that increase. After comparing both data sets, I find badblocks decrease in read throughput as block count increases interesting. Badblocks first writes to the disk and when done goes back and reads from the entire disk verifying the data. I am guessing it is a limitation of how they are checking the blocks, I will have to look at the code to see if I can find anything.
So, if you use badblocks -wb 4096 use at least -c 4096 to get highest throughput with the HP micro server.
Last edited: