Operating System - Tru64 Unix
Showing results for 
Search instead for 
Did you mean: 

wiping disks before disposal/re-sale: dd if=/dev/urandom ?

Go to solution
Joe Ledesma
Frequent Advisor

wiping disks before disposal/re-sale: dd if=/dev/urandom ?

I need to erase the data / wipe several cabinet-fulls of SBB drives.

Running 5.1 and 5.1A and wanted to experiment with /dev/random and /dev/urandom in 5.1B so didn't even both with a quick install--just booted off the 5.1B install CD. There wasn't enough entropy for /dev/random to produce anything ('cat /dev/random' hung) so am using /dev/urandom. (See the man page for the differences.)

dd if=/dev/urandom of=/dev/rdisk/dsk1c bs=8k conv=noerror

* Is this a good block size to use?

I also plan to do a SCSI format with scu.

I don't need to do this to military spec but since the disks are going to go to surplus in our organization and purchased by somebody by the pallet-load I want to follow due diligence.

The drives will end up somewhere in the world and who knows in a couple years the technology to read disks that were simply zeroed out might be cheap.

(Interestingly, there was no /dev/zero when booted off the install CD.)

Destruction was too expensive. Our off-site tape handling vendor will certify destruction of a tape for one dollar per tape but costs per disk were prohibitive.

So if this works planning to write the disk randomly three times and then format it.

I know there are utilities and commercial tools that boot DOS or some mini-UNIX and wipe the disk but I'd like to use the Alpha equipment we have. Thinking of connecting a spare DS10 machine to a BA356 shelf to make a disk-wiping station so that we can get these drives out the door.

We're consolidating on an EVA array and migrating off of the ESA10000s, SW800s, etc. I suspect other Tru64/StorageWorks shops that are consolidating storage may have similar issues with disposing of old disks.
Hein van den Heuvel
Honored Contributor

Re: wiping disks before disposal/re-sale: dd if=/dev/urandom ?

> dd if=/dev/urandom of=/dev/rdisk/dsk1c bs=8k conv=noerror
> * Is this a good block size to use?

NO. Use 1024k or anything else in the 128k - 4000k range. From 512bytes (minimal IO) or roughly 64K IO sizes the IO/sec is the limiting factor. Beyond that the MB/sec start to take over. At 1MB/IO you will eb pretty close to MB/sec saturation.

You can expect this to go 5 - 20 times quiker than the 8KB IOs


Ann Majeske
Honored Contributor

Re: wiping disks before disposal/re-sale: dd if=/dev/urandom ?


As you've seen, /dev/random was not designed with this intensive level of use in mind, /dev/urandom is a much better idea unless you don't mind spending multiple days on each disk!

Looking at the /dev/urandom device itself, it harvests data from the random pool a few bytes at a time, so the block size you use isn't going to affect the performance of actually collecting the random data. But, the random pool is populated from random data collected from key strokes, mouse movements, system interrupts, and disk accesses. So, to maintain a better quality of randomness of the data in the random pool, decreasing the block size of your writes or doing other activity on the system at the same time might help, even though it would decrease the overall performance. It's up to you to decide if its worth the extra time it would take.

Maintaining security of your data is not an absolute. Security is constrained by time and money. It's not worthwhile for you to spend more time or money on protecting your data than the loss of that data would cost. Its also not necessary for you to make the data on these disks completely irrecoverable, its sufficient for you to make it so that it would cost the new owner of the disks more time or money to recover the data than that data is worth to them. I certainly don't know enough about the value of your data to you or anyone else to tell you exactly how to go about this, but my feeling is that you're headed in the right direction :)

Joe Ledesma
Frequent Advisor

Re: wiping disks before disposal/re-sale: dd if=/dev/urandom ?

Thanks Ann for your considered reply (and Hein for your reply also).

I'm finding that even using /dev/urandom is too slow.

The bottleneck appears to be the CPU.

As a test, copying one disk to another causes 9% CPU utilization with 90% I/O wait time; copy from /dev/urandom to a disk uses all the CPU according to 'ps' and I can't even run 'vmstat'.

All I have is a DS10. Our largest production server is a GS80 but of course I couldn't use it for disk wiping!

Therefore, I'm considering falling back to our original idea from before we even considered using the new random devices in 5.1B, which is to use the disk exerciser (DILX)in the HSZ* controllers to write a fixed pattern on the disks. No host server is involved in this case. It all happens directly in the storage hardware.

(Perhaps I should open another forum question in a StorageWorks forum?)

DILX wasn't designed with our use in mind of course. DILX expects to run for a certain number of minutes so we have to run it long enough to make sure that the entire disk has been covered based on the number of blocks that the tool reports to have written. DILX can't be told to just write to an entire disk. Needless to say, this was a bit cumbersome and by the time we used this procedure on two disk cabinets I decided to look into using dd which I had originally rejected in favor of doing all the wiping inside the storage array. 'dd' of course will write the disk until complete.

With dd I also wanted to use the new random devices for greater obfuscation of the underlying magnetic data. However, this doesn't seem to be practical with the hardware I have.

Turns out HP has a service to remove old data: Data Sanitization Service. From this description:

"Using software coded to write multiple copies of deliberate bit patterns, they [HP Services] obliterate all data"


"deliberate bit patterns" sounds like a fixed pattern and not a random pattern.

Therefore, if this is good enough for HP:

"This process helps eliminate the possibility of interrogation of previously written data - even through the use of advanced forensic instrumentation. The resulting sanitization exceeds stringent industry security standards for the cleansing of electronic data."

then using a fixed pattern should be good enough for me.

So back to running DILX in the controllers.

Joe Ledesma
Frequent Advisor

Re: wiping disks before disposal/re-sale: dd if=/dev/urandom ?

I just posted this question in the forum Storage > Disk Array:

subject: HS* controllers: DILX for wiping/erasing disks--as alternative to 'dd' / HP Data Sanitation service?


Tomasz Gorka
Occasional Visitor

Re: wiping disks before disposal/re-sale: dd if=/dev/urandom ?

I was wondering whether you came up with a solution to wiping your disks.
We may be required to sanitize to military standards.
Am thinking of using scu to write 0's, 1's and something random.
Alexey Borchev
Regular Advisor

Re: wiping disks before disposal/re-sale: dd if=/dev/urandom ?

Sorry, kind of stupid idea, but:

I wolud make a big file (say, 1 Gb size) filled from /dev/urandom, and copy that down to all other filesystems by cp until full.
Or make one random disk drive and copy it to other disks by dd.

Yes, it's not _exactly_ random but looks sufficient to me...
The fire follows shedule...