Best stop doing that. Never overwrite an SSD/flash storage device completely in order to erase it, except as a last resort.
NVRAM has a limited amount of write cycles available. At some point, after enough writes to an NVRAM cell, it will completely stop working. For modern versions, we're in the ballpark of an estimated lifespan of 3,000 write cycles.
Furthermore, internally SSDs look nothing like traditional hard disks. SSDs have the following unique properties:
Spare area, often on the order of 8% - 20% of the total flash is set aside for wear leveling purposes. The end user cannot write to this spare area with usual tools, it is reserved for the SSD's controller. But the spare area can hold (smaller) amounts of old user data.
A "Flash Translation Layer", FTL. How your operating system 'sees' the SSD (LBA addresses) and the actual NVRAM address space layout has no correlation at all.
Very heavy writing to a consumer-grade SSD may bring the controller's garbage collection algorithm behind, and put the controller into a state of reduced performance. What happens then depends on the controller. In an extreme worst case scenario, it cannot recover performance. In a much more likely scenario it will slowly regain performance as the operating system sends "trim" commands.
Lastly, from the conclusion of the paper "Reliably Erasing Data From Flash-Based Solid State Drives": "For sanitizing entire disks, [...] software techniques work most, but not all, of the time."
So when you're completely overwriting flash storage, you may be performing an effective secure wipe -- but, you may also be missing some bits. And you're certainly consuming quite much of the drive's expected life span. This isn't a good solution.
So, what should we be doing?
- The 'best' modern drives support a vendor-specific secure erase functionality. Examples of this are Intel's new 320 series, and some SandForce 22xx based drives, and many SSDs which are advertised as having "Full Disk Encryption" or "Self Encrypting Drive". The method is generally something along the lines of:
- The SSD controller contains a full hardware crypto engine, for example using AES 128.
- Upon first initialization, the controller generates a random AES key, and stores this in a private location in NVRAM.
- All data ever written to the drive is encrypted with the above AES key.
- If/when an end user performs a secure wipe, the drive discards the AES key, generates a new one, and overwrites the old AES key position in the NVRAM. Assuming the old AES key cannot be recovered this effectively renders the old data unrecoverable.
- Some drives don't have the above, but do support the ATA Secure Erase commands. This is were it gets more tricky -- essentially we're relying on the drive manufacturer to implement a 'strong' secure erase. But it's a black box, we don't know what they're actually doing. If you need high security, then you should not rely on this, or at least you should read the tech docs and/or contact the drive manufacturer to verify how secure their method is. A fair guess as to what they're doing / ought to be doing is that:
- While the drive isn't using a full cryptographic cipher such as AES, it is still using extensive data compression algorithms & checksumming & RAID-like striping of data across multiple banks of NVRAM. (All modern high-performance SSDs use variants of these techniques.) This obfuscates the user data on the drive.
- Upon receiving an ATA Secure Erase command, the drive erases its "Flash Translation Layer" table, and other internal data structures, and marks all NVRAM as freed.
My personal recommendations:
If you just need an insecure wipe of an SSD, then use the manufacturer's end user tools, or use the ATA Secure Erase command via for example hdparm
on Linux.
If you need secure wipe then either:
- Only use drives which explicitly advertise secure wipe via strong (AES) encryption, and run the manufacturers secure wipe. and/or:
- Ensure that all data you write to the drive is encrypted before hitting the drive. Typically via software full disk encryption such as PGP Whole Disk Encryption, TrueCrypt, Microsoft BitLocker, BitLocker To Go, OSX 10.7 FileVault or LUKS. or:
- Physically destroy the drive.