[conspire] Secure Erase, SSD failure habits (was: successful install, at last)

[Rick Moen]

I wrote:

> Paul Zander wrote:
> 
> > The following will fill the partition with zeros.
> > 
> > dd if=/dev/zero of=/dev/sdX bs=1M
> 
> Depending on the 'X' in '/dev/sdX', you might actually overwrite not
> just a partition but an entire disc, so be careful what you type, there.
> 
> Yes, certainly you can use good ol' dd to zero-fill anything at all.
> 
> Sometimes, the aim of zero-filling is to approximate a 'secure erase' of
> disc contents, so in that case you might prefer using the shred commend,
> which is probably just a wrapper around dd, allowing the admin to
> specify how many write passes to do.  (We've covered the 'secure erase'
> thing here before, including mention of DBAN, Darik's Boot and Nuke.
> Before someone else mentions it, all of these methods are _not_ good
> enough to defeat state-level opponents wanting to recover your erased
> data.  LLNL melts disk platters that have housed secret files and will
> settle for nothing less, for example.)
> 
> I always in general prefer basic tools like dd for maintenance
> operations.  If I had a dodgy SATA or PATA drive I wanted to recover, I
> might use it _or_ try a zero-filling utility from the manufacturer on a
> theory that it might build in some extra tricks.  Dunno.  Might try
> both.

I knew I was forgetting something -- relative to both HDs and SSDs -- in
writing the above, and revisiting some of Ted T'so's discussions of
SSDs' Linux considerations
(https://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/comment-page-2/#comments)
jogged my memory.  It's this reader comment on Ted's blog:

  Ian on May 25, 2009 at 5:12 am

  I found this, helped me find out how to do the SECURITY ERASE
  http://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

Context, citing page's 1st paragraph:

  When a Secure Erase is issued against a SSD drive all its cells will
  be marked as empty, restoring it to factory default write performance.

That sentence, in turn, links to an Anandtech page that's all about
SSDs' long-term problem of performance degradation of write (but not
read) performance, how invoking ATA command 'TRIM' (either automatically
in background or as a periodic run) will perform corrective
garbage-collection.  _However_, a thorough and complete reconditioning
(of either an SSD or an HD) requires issuing ATA command 'SECURE ERASE'
as described on http://ata.wiki.kernel.org/index.php/ATA_Secure_Erase.
Note cautions, including need to avoid USB.

Summary:  To recondition a decrepit ATA-type mass-storage device (SATA HD
or SSD, PATA HD), send it ATA command 'SECURE ERASE' using utility
'hdparm'.  Expect resulting revamp to take hours.  Understand this will
blow away contents, & that preliminary steps (covered at link) are
required.

(One of many live distros furnishing hdparm, a small command-line
utility:  GParted.)


The other thing I forgot to mention (in context of comparison between
SSDs and the HDs we're all used to) is that SSDs are notorious for
giving _no warning before failing_.  The thing may just decide one day
it's pining for the fjords, and go off to join the choir invisible.
Whereas, a hard drive will usually show escalating distress (sector read
failures, etc.) that only an oblivious owner would miss, and give
him/her a chance to abandon ship in orderly fashion.  Periodic
smartmontools reports may help (assuming firmware lying to the SMART
layer isn't excessive).