6 ms·
Tangentially related. Whenever I get a new drive, I always do a "burn-in". A program writes data to the whole drive and then reads it back (reproducible rando
by fpgaminer 8y ago
Tangentially related. Whenever I get a new drive, I always do a "burn-in". A program writes data to the whole drive and then reads it back (reproducible random data).
Is there any real justification for doing this kind of test on a new drive?
Doing it takes quite awhile, so I've been wondering lately if it's even worth it. I've never found anything with it.
- conbandit 8y agoIf you've never found anything with it, why do you keep doing it (see: the definition of insanity)?
- cataflam 8y agoNot the parent, but probably because 1. It's notorious that hard drives have a higher failure rate at the beginning of their lives than in the middle (see bathtub curve [0]). So it's not absurd to test them hard early on before writing any useful data and to do an early RMA. 2. The failure rate on drives is low enough that his methodology may be right but he still never has any failure in his life. Doesn't it make insane. [0] https://en.wikipedia.org/wiki/Bathtub_curve https://en.wikipedia.org/wiki/Bathtub_curve
- kbutler 8y agoIt would depend on the effort to do the methodology vs. the expected return (savings of finding a failed drive times the probability).
- philliphaydon 8y agoI once bought a new 1TB Drive when they were fairly new. MOVED about 500gb if data to the new drive. Checked it. Seemed fine. Turned computer off and went to bed. Next day the HDD didn’t turn on. Completely dead. :( I’ve never had a failure since but I backup everything now.
- e40 8y agoI have. Last time I bought a bunch of drives for a RAID array, I used the WD utility to test each of them. 1 of the 6 failed the test.
- eps 8y ago"Failed" as in "with an IO error" as in "got the wrong data back"? Because if it's the latter, it could've been caused by some other part of IO stack and not necessarily the drive itself.
- kiwijamo 8y agoI believe the WD utility sends a command to the drive so it does a self test. That would eliminate any upper layers issues.
- hinkley 8y agoThe first time I learned about burnin, it was because the drives for our RAID array showed up three days before we were supposed to start experimenting. Two of the ten were DOA. FED-EX got us replacements in two days. One of those was dead. So then I started doing math on MTBF and lots of drives and things looked bleak. Just a couple years later MTBF had gone way up and continued to climb for a while after, but at that particular moment it was something like eight months between failure of you had any more drives than we had and just accelerated from there.
- icelancer 8y agoWhy do you back up drives if you've never had a failure?
- ridgeguy 8y agoFor the same reason you buy fire insurance even though your home has never burned down.
- jonhohle 8y agoinsanity | inˈsanədē | noun the state of being seriously mentally ill; madness I'm not sure when the definition of obsessive-compulsive started being used to describe insanity (it's been going on for at least a decade), but I don't like it (and cringe every time I hear someone repeat it).
- jrace 8y agoMe too, one could argue that practicing anything is "doing the same thing over and over expecting different (getting better) results" ================================ I too have switched to HGST thanks to the backblaze stats.
- Sohcahtoa82 8y agoThis is a very strange invocation of the definition of insanity. Apparently, quality assurance should never be a thing.
- StrangeDoctor 8y agoI do this with SD cards, I've found fakes with regards to speed and capacity. But I use ZFS for drives and just trust it to do its thing.
- cerberusss 8y agoYup, I do this with SD cards as well. To do this on the commandline, I just fill it up with big gigabyte-sized files. The loop uses "seq 1 16"; at least 15 files should fit on a 16 GB stick. $ cd /Volumes/your_new_SD_card $ dd if=/dev/urandom of=test.bin bs=10000000 count=1000 $ for i in $(seq 1 16); do cp test.bin test$i.bin; done For good measure, you could run md5/md5sum on the files.
- bluedino 8y agoIn one of their first blog posts about the pods they stated that they saw 'high infant mortality' in drives so they would burn-in each pod for a few days before writing any customer data to one.
- fpgaminer 8y agoThank you. Found the post: https://www.backblaze.com/blog/alas-poor-stephen-is-dead/ https://www.backblaze.com/blog/alas-poor-stephen-is-dead/ They have another good idea in there: recording the SMART data before and after the test. Their theory is that even if SMART attributes are still OK after the test, looking for a trend in the attributes may point to eventual failure later. Nice.