[COLUG] Clearing your data from an HDD (was Re: Drive Wiping Speed)

William Yang wyang at gcfn.net
Fri Sep 14 07:03:57 EDT 2007


jep200404 wrote:
> David Sherman wrote:
> 
> 
>>I prefer an empty hard drive ...
> 
> 
> dd if=/dev/zero of=/dev/hda

I don't know what the specific application for that was, but this seems 
as good a time as any to talk about clearing drives before repurposing.

I've recently come into a few systems that contain a bunch of 
proprietary information through my consulting business.  Now, I could 
just use DBAN to clear them and be done with it, but that requires that 
I burn YACDI (Yet Another CD Image).  I've found, with a reasonably 
large music case full of media of things I've had to burn, that this is 
starting to get annoying to me.  Furthermore, simply using DBAN doesn't 
really teach me much, so I'm thinking through the process of cleaning disks.

I've looked at DBAN.  It's got a several methods to clean a disk, but 
unless I really have misunderstood it, it's not really doing anything 
I'm terribly concerned about on modern equipment.  My understanding and 
research lead me to believe that 8 destructive passes with data streamed 
from /dev/urandom to a drive is probably sufficient, which means I'm 
likely to do:

#! /bin/sh
#
# THIS CODE DESTROYS DATA ON DISKS.
# IT IS *INTENDED* TO MAKE SUCH DATA AS NON-RECOVERABLE AS REASONABLY
#  POSSIBLE.  YOU MUST BE EXTREMELY CAREFUL USING THIS CODE.
#
DISK=/dev/nosuchdevice

for t in 1 2 3 4 5 6 7 8 ; do
	dd if=/dev/urandom of=$DISK bs=16k
done
# because it makes sense to have a clean disk, and it doesn't take that 
# long
dd if=/dev/zero of=$DISK bs=1M

#=-= end code


/dev/urandom is significantly slower, of course -- given that it's doing 
a hash on seed data, even if it's reusing its entropy base, it's much 
more computationally expensive.  But how much so?

The base throughput test was simple:

for dev in urandom zero ; do
	test -f testfile && /bin/rm -f testfile
	dd if=/dev/$dev of=testfile bs=1M count=16
	test -f testfile && /bin/rm -f testfile
done

 From a performance standpoint, I should have used the same Gentoo 
2006.1 minimal LiveCD, doing reads from a devfs /dev/urandom and 
/dev/zero, and writing to a ramdisk section of the filesystem, to 
eliminate the disk IO factor (what I used on the 800Mhz -- I actually 
used existing OS's on the other two machines).  Even confounded by disk 
IO on the latter two machines, you can see the trend based on the 
controlling CPU and IO bus to RAM factors.  Every machine has memory 
that's properly matched to its bus.

1)  A Celeron 800Mhz machine

	urandom	16777216 bytes (17 MB) copied, 15.6097 s, 1.1 MB/s
	zero	16777216 bytes (17 MB) copied, 0.15252 s, 110 MB/s

2)  A Celeron 2.53 Ghz machine (devfs to disk)

	urandom	16777216 bytes (17 MB) copied, 4.49014 s, 3.7 MB/s
	zero	16777216 bytes (17 MB) copied, 0.0612527 s, 274 MB/s
	
3)  A Core 2 Duo 1.66 Ghz machine (devfs to disk)
	
	urandom	16777216 bytes (17 MB) copied, 3.72988 s, 4.5 MB/s
	zero	16777216 bytes (17 MB) copied, 0.039693 s, 423 MB/s

Net result:  /dev/zero is about 8x to 10x faster than /dev/urandom...

But you should still use it when you're clearing disks if you're 
concerned about confidentiality of data before you give a disk away or 
reuse it.

-- 
William Yang
wyang at gcfn.net


More information about the colug432 mailing list