2

I have a collection of new drives, a friend recommended I run badblocks on the new drives before using them. I ran badblocks on some of the new drives before imaging them badblocks -v -s -w -b 4096 -o ./sda.log /dev/sda, other drives I imagined new without badblocks. ps I also ran conveyance smart tests on the badblocks drives, passed.

For the drives that I ran badblocks on, read throughput after imaging is very low dd if=/dev/sda bs=4096 of=/dev/null count=1M with caches dropped average's 71.1MB/s. For the drives that were just burned with a disk image, the average read rate is 195MB/s.

Did I "break" these drives by running bad blocks? Can I recover/reset them?

Smart shows a

  • high spin-up time for the badblocks'd ~3000 (0 for new drives)
  • Zero read error and zero sector relocation on all drives.
  • self-test's pass on all drives
  • otherwise nearly identical smartctl -a reports
Improve this question
1
  • 1
    so, after zeroing read performance was still bad ~20MB/s. I found out these are for-sure SMR drives, oops. After a few days idle, and a power cycle one drive returned to the expected 180MB/s. brand new drives with contiguous serial numbers often have their first cold read ~400MB/s which seems like "intelligent firmware", just using a linux kernel so idk if the os is aware of smr and to what degree it is cooperating with the drives. SO to answer my own question, the drives were not broken by badblocks.
    – ThorSummoner
    Nov 5, 2021 at 4:29

1 Answer 1

Reset to default
1

Partial answer:

badblock -w actually writes every single block instead of just reading it, so you've done a "destructive" test instead of the normal "non-destructive" test.

That could be a difference, in particular if the image you've written is smaller than the total capacity of the harddrive. The harddrives that only have the image have the higher numbered blocks untouched, the harddrives with badblock have a pattern in the higher numbered blocks.

But I fail to see how this can impact throughput.

high spin-up time for the badblocks'd ~3000 (0 for new drives)

Spin-up 0 sounds like the value is not set yet - no harddrive can spin up in no time. Does the value stay 0 even after you've power cycled them a few times?

Including some actual SMART reports in the question could help.

Zero read error and zero sector relocation on all drives.

What about seek errors? They actually can have an impact on throughput.

If you want to experiment (this is a shot in the dark): Take one or two of the badblock'd harddrives, write zero to all the blocks with dd (that will overwrite the pattern that badblk used), reimage harddrive, see if it makes a difference.

If it does, then the firmware treats "zero" blocks differently from blocks with "data" somehow. For whatever reason.

Another idea is that the harddisk possibly has some fast cache, maybe flash memory, which would serve to make the harddisk look good in tests that measure read and write speed in a simple way. So they could write great numbers into the data sheet to boost sales which are not actually achieved in real operation. And doing the badblk writes "overflows" the cache so the firmware decides that it can no longer be used.

Improve this answer
3
  • ty much for input dirkt. badblocks write mode is by intention to "confirm safety" before use, i trust the manufacturer anyway. badblocks finishes with a 0x00 pattern so it should be "blank" when complete, the written images are half the device size. spin up tbd, i expect these valves are normal. how to "undelete" a Linux block device without rebooting to test power cycling. no errors of any kind in smart, the non zero smart values are the temperature, everything else virtually no diff on all drives. the suggested zero test i plan on, as well as ata erasure.
    – ThorSummoner
    Oct 23, 2021 at 6:38
  • 1
    when pulling the presently love images off the "slow" drives i got an average 122MB/s for the whole device which is better than the very slow 60-70MB/s read from "dd the first 4GB" and "hdparm -t" but still worse than the "166 MB/s average" (dd4G, hdparm and dd all agree)'d device read's I'm getting from the other devices that weren't badblocks'd. it definitely feels like the device firmware is doing something screwey, and maybe these "166MB/s reads" are non-real-world performance numbers, enhanced by magic firmware. maybe "over time" all drives will "settle down to 60MB/s" idk what to expect
    – ThorSummoner
    Oct 23, 2021 at 6:48
  • 1
    fwiw, a read back of the bytes past the image size came back all zero dd if=/path/to bs=4096 skip=805306368 | od, so if the firmware is treating something as being different, it shouldn't be zero blocks based
    – ThorSummoner
    Oct 26, 2021 at 0:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .