Bulk erased drives

Spinrite is rubbish on modern drives. Does nothing useful other than line the promoter's pockets.

Only for windoze weenies :)

Grant.

On a sunny day (Sun, 27 Jun 2010 03:00:09 +0100) it happened Nobody wrote in :

I am sure I bought some 40 GB Seagates in 2001 Just found the bill, 1 40GB 5400 rpm IDE ATA 100 04-05-2001 And it is still working! Seagate is really good.

You're such a retard. Keep current, dumbass.

You have been out of the loop too long, old fucktard.

The only system you ever integrated was shoving your finger up your ass.

Some of the CRAP you total retards spew is amazing.

So typical of total, know nothing retards, taking a stab at the world. You missed, idiot.

You're a jerk. A complete kneebiter.

When AlwaysWrong accuses a kettle of being black, he doesn't screw around!

That's some statement from someone who is *always* wrong, AlwaysWrong.

Wrong again, AlwaysWrong. We consistently hit the idiot; *YOU*.

DimBulb is back to the scat fetish.

If you really want to securely erase a drive, an oxy-acetylene torch on the platters takes some beating ;-)

dd(1)'s use of "files" is only in the sense that devices (including the pseudo-device "zero") reside in the filesystem as a common namespace. The dd(1) invocation opens the disk device (raw or block, depending on the minor device number associated with the name used to access the physical device)

The difference lies in how much is passed to fwrite(3c) in each invocation (i.e., how much overhead the API incurs as you push bytes across it)

Again, it's not really a *file* but, rather, an interface to a bdevsw associated with the "disk drive".

I had a few minutes, yesterday, to play with a couple of them.

The drives (regardless of manufacturer) exhibited similar symptoms. On power up, the head positioner would "clank" noisily and continuously. As if the heads were being loaded and unloaded (to use a somewhat dated term that hopefully conjurs up the right imagery in suitably aged minds :> ).

The probe() for the device would continuously hang spouting a fixed sequence of errors (e.g., seek failure, timeout, etc.).

Unfortunately, an irrational, deep-seated dread of that head noise left me unable to let a drive do this to itself for more than 15 - 20 seconds. :<

When I have more time, I'll try a few experiments:

- power up drive *without* controller to see if the drive's internal diagnostics have it thrashing thusly in the absence of any external commands

- remove enclosure and watch to see what's really happening

- remove enclosure from a known *good* drive and prevent it from getting any flux changes from the platters and see how *it* responds

But, I'm sticking with my initial assumption that the drives are irrecoverable due to lost servo information.

Drill a hole through it where the plater(s) are/is at.

That will dramatically increase the cost of recovery, but it won't prevent it.

Overwriting will provide better protection and you can re-use the drive.

Yes, it would. Only the flat portions would be able to have ANY data pulled from them. And that extraction takes more expensive gear than all but the federal boys have.

The best way is to use RAID5 and bit strip your drives. Then when one fails, there is no recoverable data from it at all. Throw it away and move on.

Three-letter agencies can probably still get useful information off, if they think it's worth spending five-figure sums on.

Most any way you slice it those drives seem to be fluxed up good.

(sigh) Yes, its unfortunate -- we probably have 1,300 machines that need drives. This would have been a good start! :<

Much too large. And, we surely aren't going to spend $80/drive to GIVE THE MACHINES AWAY!