Hi all,

I'm trying to wipe out an SSD drive and prepare it for new use.

Normally, I wipe a drive by using:

(The 128k blocksize increases efficiency and speeds up the wipe.)

While this works fine on an SSD, I've read that SSDs actually are at their "virgin" state when the blocks contain all bits on (i.e. 0xFF characters). Therefore, it would stand to reason that writing 0x00 characters actually "uses up" the SSD and would cause the effect that any and all data written to it from then on would require an erase/write cycle.

Since I'm working with an older SSD that doesn't have TRIM support I wanted to do this to "virginize" the SSD. This is for a low I/O application and it is feasible for me to manually script a way to delete data off the SSD by filling the file to be deleted with 0xFF characters. Not as efficient as TRIM but better than nothing. Either way, though, it's best to start with a cleared SSD.

The point is, I'd like to be able to use dd to write something other than zeroes to the drive.

I decided to write a tiny C program like this:

and then pipe that program's output into dd:

This works, but the little app quickly shoots up to 100% CPU usage and the zeroing process is very, very slow. (about 5MB/sec on an SSD capable of writing well over 50MB/sec)

Is there a more efficient way to basically generate tons of 0xFF characters so that I can push them into dd?

Thought of using "yes" but this adds LF characters and also generating the initial 0xFF is a bit of a pain.

Ideas?

Thanks

F

What you are doing is pointless. First, you are not overwriting the stored data. For each block that you write, the controller in the SSD puts the current block into the "dirty, pending erase" queue and allocates a new, already erased block. Second, the blocks that you have just written with all ONEs (which. BTW, might not be the bit pattern that is actually stored in the cells) are now considered "busy" with user data. The next time they are written to, they will again be moved to the "dirty" queue and a new, erased block allocated. You have accomplished nothing except to waste some of the lifetime write cycles of the device.

Without TRIM support in the device or some other way to tell it to re-initialize itself, there is simply no way to do what you are attempting.

dd if=/dev/zero of=/dev/sda conv=swab bs=8192k

SWAB will take the input 0x00 and swap it to 0xff for the write.

A larger blocksize should make it fly.

No, it won't. I don't know where you go that idea. "conv=swab" merely takes each pair of consecutive input bytes and interchanges them. About the only time you would want to do that would be if you had a file full of 16-bit binary numbers and wanted to convert them between little-endian and big-endian format.

The answer has been posted before:

http://www.linuxquestions.org/questi...v-zero-619626/

However, I recommend using the 'wipe' utility to wipe a disk with random data if you are concerned that wiping with zeros is not enough.

My comment stands corrected by "rknichols".

# od --output-duplicates --format=x 0011.dat

0000000 00110011 00110011 00110011 00110011
0000020 00110011 00110011 00110011 00110011
0000040 00110011 00110011 00110011 00110011
0000060 00110011 00110011 00110011 00110011
0000100

# dd if=0011.dat of=1100.dat conv=swab
0+1 records in
0+1 records out
64 bytes (64 B) copied, 0.000236 seconds, 271 kB/s

# od --output-duplicates --format=x 1100.dat

0000000 11001100 11001100 11001100 11001100
0000020 11001100 11001100 11001100 11001100
0000040 11001100 11001100 11001100 11001100
0000060 11001100 11001100 11001100 11001100
0000100

I write the binary differently than using ( tr ), not the ultimate solution, just another method. I liked this method better because I could tailor the length of the output and not just ( ctrl-c ) when redirecting in to ( tr ) from /dev/zero


#!/bin/ksh

OutputFile="binary.dat"
integer i=0

while (( i < 64 ))
do
printf "\u11\u00" >> ${OutputFile}
(( i = i + 1 ))
done

If random data will do, why not use /dev/random (or /dev/urandom) instead of /dev/zero?

Using the wipe utility is much faster, I tested it.