Fast disk wiper?

[mikeblas]

I use Active@ KILLDISK to erase drives I'm done with. It's excruciatingly slow -- it's only writing at about 3 megabytes/second to a drive that's capable of better than 50 megabytes/second.

What's wrong with it? Are there alternative programs that are faster?

 

[Vertigo Acid]

dd if=/dev/urandom of=/dev/harddrive bs=1204
Rinse, repeat as many times as you'd like

 

[Glacian22]

Also, I believe there's a free program called Derrick's Nuke'n Burn, or something like that.

 

[mikeblas]

I'm not running Linux. Is your suggestion that I use a live CD and ty this command? Will the dd command show progress? Is your suggested blocksize of 1204 a typo for 1024, or a suprising optimization? Why not 4096 or 8192?

What write rate can I expect?

Derrick's Nuke'n Burn

How fast is it?

 

[bbz_Ghost]

Eraser is one of the best, powered by DBAN, aka Darick's Boot and Nuke.

This kind of process takes time, regardless of how fast the drive is, so get ready for a wait. It's a sector-by-sector process, so again, it doesn't matter how fast the drive is, it's going to take time to complete. If you choose to do multiple passes, each one just adds that much more time.

If you want fast get a bulk eraser or wave the drive over the magnet of an 18" or larger subwoofer several times. That'll wipe it... fast.

 

[mikeblas]

It's a sector-by-sector process, so again, it doesn't matter how fast the drive is,

How do you figure that? Filling the drive with zeroes is just a very long, sustained sequential transfer. Why do you think that the performance of the drive is irrelevant?

 

[Vertigo Acid]

Yeah, Live CD would work great. Only caveat is that you may have to play with HDParm if DMA settings aren't correct. As for the block size, yes, that's a type. Should be 1024, TBH I don't know the origin of that, but, it's what the canonical example using dd shows. :shrug:
No progress, but, it should write as fast as your drive can handle...

 

[digital_exhaust]

wave the drive over the magnet of an 18" or larger subwoofer several times. That'll wipe it... fast.

Won't that actually destroy the drive?

And understand I'm only asking, as I've never actually done that myself, but from what I have read, there are servo tracks written on the disk, that if erased, will leave a drive useless.
Please correct me if I'm wrong, I would just like to know if this is true or not.

And, if destroying the drive is the goal, there has got to be amore entertaining way to do it than waving it over a big magnet

 

[mikeblas]

Drives still (amazingly) use 512 byte pyhsical sectors. I wonder why, then, 1024 is given in that example.

Indeed, a magnet will also attack the positioning and servo tracks. If the drive needs to be securely erased, this is fine. For me, I don't need such measures. If I had to go for the most entertaining method, I'd just use the drill press.

 

[bbz_Ghost]

The OP merely asked for a wiper, so Eraser/DBAN/dd or a bulk eraser/powerful magnet are the solutions. There's nothing on the platters that needs to be worried about as the MBR is rewritten everytime the drive is powered up from the ROM/PROM on the drive.

The only possible concern would be as mikeblas mentioned: there's a possibilty that using a magnet might actually move the head assembly from it's parked position and do physical damage to the heads or possibly the platters as well.

Considering that drives typically have way over 100G's (not Gigabytes, I'm talking about the G-force rating) of resistance, and no magnet that I'm aware of is going to have that kind of pull, I'd say the chances of destroying a hard drive just by waving it over a subwoofer magnet a few times is between null and void.

I've used that method hundreds of times over the years in both home and corporate environments. I know Unix/Linux hardcore people that swear by dd, and that's fine for them, but when the boss says "I need <xxx> amount of storage, pronto" and we have spares that need to be securely wiped, there's no better friend that I know of than a Neodymium 6 lb magnet on a Cerwin Vega 18" sub.

I had that happen once, a manager ran in and asked me to securely wipe his drive. I took the drive, said "I'll be right back," walked out to my car, popped the trunk, opened the sub enclosure in my 79 Monte Carlo, waved it over the 18" sub magnet 3 times, closed the enclosure, closed the trunk, went back and handed it to him and he just scoffed at me.

Of course he wanted proof, I plugged it in, ran a data recovery app on it and it came up nil, as expected. QuickFormatted it, handed it back and said "Have a nice day." He just smirked and walked out.

"I get no respect, no respect I tell ya..."

 

[mikeblas]

The OP merely asked for a wiper, so Eraser/DBAN/dd or a bulk eraser/powerful magnet are the solutions. There's nothing on the platters that needs to be worried about as the MBR is rewritten everytime the drive is powered up from the ROM/PROM on the drive.

The drive doesn't have a copy of the MBR in ROM. It can't; the MBR changes depending on what's installed on the drive and how the drive is partitioned.[/QUOTE]

The only possible concern would be as mikeblas mentioned: there's a possibilty that using a magnet might actually move the head assembly from it's parked position and do physical damage to the heads or possibly the platters as well.

I think you've misunderstood my post. Some drive designs use one surface of a platter that doesn't store any data. Instead, it's recorded at the factor yto help the drive locate tracks. The idea is that the signal strength for the signal read by that head will provide the seeking mechanism with feedback about the location of the heads, and help it seek accurately.

Using a magnet will erase these positioning tracks as well as the data tracks. This has nothing to do with using an external magnet to physically move the heads.

I'm still waiting to hear why you think writing data to the disk to overwrite and obscure existing data is any is different than writing data to the disk for application use. Active@KILLDISK is writing at about 2.5 megs/second, which is painfully slow. Why do you believe this writing process is any different than writing application data to the drive, and not governed by the drive's sustained write performance limits?

 

[unhappy_mage]

I'm still waiting to hear why you think writing data to the disk to overwrite and obscure existing data is any is different than writing data to the disk for application use. Active@KILLDISK is writing at about 2.5 megs/second, which is painfully slow. Why do you believe this writing process is any different than writing application data to the drive, and not governed by the drive's sustained write performance limits?

For certain IDE controllers (the one on the Intel 945 chipset, for example), the Linux IDE drivers aren't done yet, so DMA doesn't work. That would slow things down considerably.

Also, I believe Linux tries to do large blocks of I/O - 128k is the default size. This is broken down into sectors, yes, but I think there's something about the block device handler that likes 128k chunks.

Last point: DBAN may do multiple passes depending on which kind of wiping you select. But it does use DMA and so forth when available, so it gets good performance in most cases. The topic on performance in their forum has some major factual issues, and I haven't run DBAN myself recently, so I can't comment further on that.

 

[drizzt81]

Drives still (amazingly) use 512 byte pyhsical sectors. I wonder why, then, 1024 is given in that example.

Could it be that when writing sector by sector, each write command is issued after the previous one has completed? If sector N's completion command is received when the head is at sector N+2 on the platter, we will need to wait for almost a full rotation until we can write N+1.

 

[mikeblas]

Could it be that when writing sector by sector, each write command is issued after the previous one has completed? If sector N's completion command is received when the head is at sector N+2 on the platter, we will need to wait for almost a full rotation until we can write N+1.

Could be, but that would surprise me. The IBM PC ROM BIOS supported multi-sector writes to drives as early as 1984. (Or whenever it first shipped.) [1]

For certain IDE controllers (the one on the Intel 945 chipset, for example), the Linux IDE drivers aren't done yet, so DMA doesn't work. That would slow things down considerably.

Sure would. But are IDE DMA workings from chipset to chipset really that much different? The motherboard involved is using a 845 chipset, I believe -- which is pretty old. And I've noticed very slow writes even on much older machines, like my 440-BX based dual proc rig.

 

[unhappy_mage]

Sure would. But are IDE DMA workings from chipset to chipset really that much different? The motherboard involved is using a 845 chipset, I believe -- which is pretty old. And I've noticed very slow writes even on much older machines, like my 440-BX based dual proc rig.

Well, I'd guess not much different, but with disk controllers you want to be *sure* Thus, PIO support in the Linux kernel usually comes fairly quickly, and DMA support somewhat later.

However, if you use DBAN you'll find that the ICH4 chipset is well-supported by now. Generally there are only DMA issues with new chipsets, or rare chipsets. ICH4 is neither.

Active@Killdisk appears to be DOS based. When was the last time IDE drivers for DOS were updated?

 

[mikeblas]

When it loads, it says something about isolinux, then something about FreeDOS. I'd expect that the FreeDOS drivers have been updated more recently than the MS DOS drivers.

Anyway, I'll give DBAN a twirl next time I have to erase something.

 

[drizzt81]

Could be, but that would surprise me. The IBM PC ROM BIOS supported multi-sector writes to drives as early as 1984. (Or whenever it first shipped.) [1]

Be that as it may, I do not know exactly how dd works.

I have a Linux machine sitting here idly. I just wrote a quick script to see if there is a difference in terms of BS... give me an hour or two.

dd if=/dev/zero of=/large/largefile bs=512 count=16777216
16777216+0 records in
16777216+0 records out
8589934592 bytes (8.6 GB) copied, 244.678 seconds, 35.1 MB/s

dd if=/dev/zero of=/large/largefile bs=1024 count=8388608
8388608+0 records in
8388608+0 records out
8589934592 bytes (8.6 GB) copied, 249.235 seconds, 34.5 MB/s

dd if=/dev/zero of=/large/largefile bs=2048 count=4194304
4194304+0 records in
4194304+0 records out
8589934592 bytes (8.6 GB) copied, 254.588 seconds, 33.7 MB/s

dd if=/dev/zero of=/large/largefile bs=8192 count=1048576
1048576+0 records in
1048576+0 records out
8589934592 bytes (8.6 GB) copied, 239.803 seconds, 35.8 MB/s

dd if=/dev/zero of=/large/largefile bs=65536 count=131072
131072+0 records in
131072+0 records out
8589934592 bytes (8.6 GB) copied, 240.779 seconds, 35.7 MB/s

dd if=/dev/zero of=/large/largefile bs=131072 count=65536
65536+0 records in
65536+0 records out
8589934592 bytes (8.6 GB) copied, 242.442 seconds, 35.4 MB/s

dd if=/dev/zero of=/large/largefile bs=524288 count=16384
16384+0 records in
16384+0 records out
8589934592 bytes (8.6 GB) copied, 238.634 seconds, 36.0 MB/s

dd if=/dev/zero of=/large/largefile bs=1048576 count=8192
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB) copied, 243.968 seconds, 35.2 MB/s

dd if=/dev/zero of=/large/largefile bs=4194304 count=2048
2048+0 records in
2048+0 records out
8589934592 bytes (8.6 GB) copied, 242.025 seconds, 35.5 MB/s

dd if=/dev/zero of=/large/largefile bs=512 count=16777216
16777216+0 records in
16777216+0 records out
8589934592 bytes (8.6 GB) copied, 248.883 seconds, 34.5 MB/s
dd if=/dev/zero of=/large/largefile bs=1024 count=8388608
8388608+0 records in
8388608+0 records out
8589934592 bytes (8.6 GB) copied, 247.167 seconds, 34.8 MB/s
dd if=/dev/zero of=/large/largefile bs=2048 count=4194304
4194304+0 records in
4194304+0 records out
8589934592 bytes (8.6 GB) copied, 260.305 seconds, 33.0 MB/s
dd if=/dev/zero of=/large/largefile bs=8192 count=1048576
1048576+0 records in
1048576+0 records out
8589934592 bytes (8.6 GB) copied, 246.05 seconds, 34.9 MB/s
dd if=/dev/zero of=/large/largefile bs=65536 count=131072
131072+0 records in
131072+0 records out
8589934592 bytes (8.6 GB) copied, 243.323 seconds, 35.3 MB/s
dd if=/dev/zero of=/large/largefile bs=131072 count=65536
65536+0 records in
65536+0 records out
8589934592 bytes (8.6 GB) copied, 245.793 seconds, 34.9 MB/s
dd if=/dev/zero of=/large/largefile bs=524288 count=16384
16384+0 records in
16384+0 records out
8589934592 bytes (8.6 GB) copied, 242.924 seconds, 35.4 MB/s
dd if=/dev/zero of=/large/largefile bs=1048576 count=8192
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB) copied, 241.025 seconds, 35.6 MB/s
dd if=/dev/zero of=/large/largefile bs=4194304 count=2048
2048+0 records in
2048+0 records out
8589934592 bytes (8.6 GB) copied, 241.562 seconds, 35.6 MB/s

apparently block size makes little difference, however I am surprised that my 500GB seagate7200.10 is doing so poorly.

 

[gjvrieze]

I use shred which is on most live cds, i always use the gentoo live cd though......works great and is pretty fast on modern hds...

 

[taqueso]

DBAN has worked great for me a couple times in the past month. I am wiping a 120GB samsung SATA drive right now at 56MB/s. The other time I used it was some 40GB IDE drive (but running on a dual xeon machine), got about 40MB/s (I'm not sure on the exact number) that time, which is probably about right for the disk max as it was about 3 years old.

edit: DBAN estimates that the 120GB drive will take 4h 15m to wipe with default settings (DoD Short, 3 passes, 1 w/ verify, Mersenne Twister PRNG)

 

[taqueso]

apparently block size makes little difference

The kernel has a good system for combining read and write requests when possible. Since dd will just issue a ton of reads and writes in sequential order, basically regardless of block size assuming the total size is generally much larger than block size, they are prime candidates for being combined into one larger request. So most sane block sizes in dd will run at about the same speed with only a small variance in CPU overhead. A really small block size in dd is still inefficient because it causes more system calls than a larger size.

also your speeds would be better if you write directly to a partition/disk instead of to a file