75

I've just received my new SSD since the old one died. This Intel 320 SSD supports TRIM. For testing purposes, my dealer put Windows on it, but I want to get rid of this and install Kubuntu on it.

It does not have to be a "secure wipe", I just need the empty the disk in the most healthy way. I believe that dd if=/dev/zero of=/dev/sda just fills the blocks with zeroes and thereby taking another write (correct me if I'm wrong).

I've seen the answer How to enable TRIM, but it looks like it's suited for clearing empty blocks, not wiping the disk.

hdparm seems to be the program to do it, but I'm not sure if it clears the disk OR cleans empty blocks. From its manual page:

  --trim-sector-ranges
          For  Solid State Drives (SSDs).  EXCEPTIONALLY DANGEROUS. DO NOT
          USE THIS OPTION!!  Tells the drive firmware to discard  unneeded
          data  sectors,  destroying  any  data that may have been present
          within them.  This makes those sectors available  for  immediate
          use  by  the firmware's garbage collection mechanism, to improve
          scheduling for wear-leveling of the flash  media.   This  option
          expects  one  or  more  sector range pairs immediately after the
          option: an LBA starting address, a colon, and  a  sector  count,
          with no intervening spaces.  EXCEPTIONALLY DANGEROUS. DO NOT USE
          THIS OPTION!!

          E.g.  hdparm --trim-sector-ranges 1000:4 7894:16 /dev/sdz

How can I make all blocks appear as empty using TRIM?

Community
  • 1
Lekensteyn
  • 174,277
  • Good question, maybe it's enough to just delete the NTFS filesystem? – htorque May 12 '11 at 14:11
  • @htorque: "maybe" is still not confirming, any useful sources would be welcome. – Lekensteyn May 12 '11 at 14:19
  • 1
    Hence it's just a comment. ;) However, you could first check some sectors on that partition sudo dd if=/dev/sda iflag=direct bs=512 skip=<some_sectors> count=32 | hexdump -C, then delete the NTFS partition using a recent Gparted version and re-check with the same command - if the data got wiped, you'd just see zeroes. – htorque May 12 '11 at 14:38
  • 1
    @htorque: I've just tested it but it's not working, I've used hexdump -C /sda1 and hexdump -C /sda1 to determine the starting block. Nice idea though. – Lekensteyn May 12 '11 at 15:04
  • Would have been too easy, wouldn't it? :) Anyways, thanks for trying! – htorque May 12 '11 at 15:06
  • @Lekensteyn - with a modern SSD I really wouldn't worry about one more write. That isn't what will kill it:-) Read Jeff Atwood's take. http://www.codinghorror.com/blog/2011/05/the-hot-crazy-solid-state-drive-scale.html – Rory Alsop May 12 '11 at 15:44
  • @Rory: (haven't read the article yet) the controller I guess? That killed my last SSD. By the way, I'm worried about the performance, see also http://www.anandtech.com/show/2865/2 – Lekensteyn May 12 '11 at 15:46
  • 1
    @Lekensteyn - I meant it slightly tongue in cheek and popped a proper answer for you below. Jeff's article has a bit on performance as well, which is why he uses them despite the failure rate:-) – Rory Alsop May 12 '11 at 15:49
  • 3
    I still don't see why you need to erase it... why can't you just reformat it with Ext4 or whatever? – Nathan Osman Jun 12 '11 at 19:25
  • See http://www.anandtech.com/show/2865/2 – Lekensteyn Jun 12 '11 at 19:29

6 Answers6

70

ATA Secure Erase

You should use the drive's security erase feature.

  1. Make sure the drive Security is not frozen. If it is, it may help to suspend and resume the computer.

    $ sudo hdparm -I /dev/sdX | grep frozen
       not     frozen

    The (filtered) command output means that this drive is ”not frozen” and you can continue.

  2. Set a User Password (this password is cleared too, the exact choice does not matter).

    sudo hdparm --user-master u --security-set-pass Eins /dev/sdX

  3. Issue the ATA Secure Erase command

    sudo hdparm --user-master u --security-erase Eins /dev/sdX

Note:

  • /dev/sdX is the SSD as a block device that you want to erase.
  • Eins is the password chosen in this example.

See the ATA Secure Erase article in the Linux kernel wiki for complete instructions including troubleshooting.

David Foerster
  • 36,264
  • 56
  • 94
  • 147
psusi
  • 37,551
  • Thanks for the link, it looks good for those who have a BIOS that supports it, but mine does not appear to support it. (frozen) – Lekensteyn May 12 '11 at 15:42
  • Hurrah! After reading the article again, I read "Placing my system into "sleep" (Clevo M865TU notebook) worked too---and this may reset other drives to "not frozen" as well." and tried it since mine is originally from Clevo as well (but BTO build it). It works, I see "not frozen" now. ... but step 3 failed with "ERASE_PREPARE: Bad address" because I replaced sudo by time instead of prepending to the command! – Lekensteyn May 12 '11 at 15:58
  • 1
    OMG it worked and only took 19 seconds! Thanks a bunch! I wish I could upvote you ten times :D – Lekensteyn May 12 '11 at 15:59
  • @Ashimema: The link is currently broken because kernel.org had been hacked and therefore down for maintenance. Google Cache is empty, but this blog copied it: http://peter.membrey.hk/2011/09/11/secure-erase-wiki-no-long-available-instructions-on-how-to-securely-erase-your-ssd/ – Lekensteyn Sep 25 '11 at 10:27
  • I just wanted to report that the accepted answer above has a broken link. It's pretty useless without said link, anyone care to post a summary of what that link said? – Ashimema Sep 25 '11 at 10:21
  • On a Kingston SSDNow V100 (64GB), this erase process took noticebly longer, namely 7 minutes. – Lekensteyn Jun 15 '14 at 09:08
  • Note: This does not work over USB (as is mentioned in the link given above but which I only read after trying). P.S. Thank you! – loxo Feb 06 '15 at 08:48
  • I tried this on two drives attached via USB and it worked exactly as described. Am running Mint 17.2 with Kernel 3.19.0-25-generic on a Thinkpad X230. – Kendor Sep 04 '15 at 19:32
  • 1
    What is the reason for recommending secure erase rather than --trim-sector-ranges? – kasperd Oct 12 '15 at 09:09
  • @kasperd, only that it it is likely to be faster since it is only a single command, vs many ( one for each x size block of space ). – psusi Oct 12 '15 at 17:25
  • 1
    @psusi The potential issues with security settings, and having to deal with setting a password sounds more significant to me than waiting a few minutes for some TRIM commands to be issued. And secure erase sounds like overkill. Doesn't the need for secure erase to ensure that data is gone immediately and cannot be recovered mean that it causes more wear on the SSD than a simple TRIM which just needs to ensure that cells are ready for reuse and not necessarily unrecoverable immediately? – kasperd Oct 12 '15 at 18:56
  • I suppose you mean the first command is hdparm -I /dev/sdX. – jarno Nov 29 '15 at 16:15
  • @kasperd, whether the erase is done now ( for secure erase ) or postponed until later ( for trim ), the wear on the cells is the same. In fact, the wear may be less with the secure erase since with trim, the drive might have to make several commits to the flash translation log before all of the trims have been issued. With the secure erase, it is just one full drive erase. This is another reason why it tends to be faster. – psusi Nov 29 '15 at 16:26
  • @jarno, good catch; fixed it. – psusi Nov 29 '15 at 16:27
  • FYI, if it does say frozen, suspend the system and log back in to return it to a not frozen state. The other option is to unplug the sata cable from the drive while the machine is running, but you have to be very careful when doing so. – Hatem Jaber Jul 20 '17 at 12:35
  • @HatemJaber, I'm pretty sure that it is the power you have to remove, not disconnect the SATA cab le, in order to get the drive to unlock. I guess power is included if you have the wide SATA connector but most people still use the small connector and separate molex connector for power, at least in desktops. Pulling those is dangerous, but the full SATA connector with power is hot plug safe. – psusi Jul 21 '17 at 00:40
  • @psusi, I read that somewhere and fortunately did not have to do that; I actually seen that as a suggestion on several sites as I was researching the topic. Thanks for the info! – Hatem Jaber Jul 24 '17 at 17:29
  • I had an unresponsive drive, freezing whole computer after some activity. Tried to clean it by above process, but the result is, that now even hdparm -I /dev/hdX reports Model Number: SandForce{200026BB} instead of Model Number: INTEL SSDSC2BF180A5L it reported before the erase. Fdisk reports 32768 bytes of drive capacity, so it seems things are now even worse, than before. Use with extreme care! – Maciej Łoziński Feb 14 '22 at 10:33
  • @MaciekŁoziński, that tends to happen when an SSD dies. It's now reporting what the controller actually is since it can't read the drive model information from the dead flash. – psusi Feb 24 '22 at 19:16
43

util-linux 2.23 offers blkdiscard which discards data without secure-wiping them. I tested: works over SATA and mmcblk but not USB.

An excerpt from the manual page of blkdiscard(8):

NAME

blkdiscard - discard sectors on a device

SYNOPSIS

blkdiscard [-o offset] [-l length] [-s] [-v] device

DESCRIPTION

blkdiscard is used to discard device sectors. This is useful for solid-state drivers (SSDs) and thinly-provisioned storage. Unlike fstrim(8) this command is used directly on the block device.

By default, blkdiscard will discard all blocks on the device. Options may be used to modify this behavior based on range or size, as explained below.

The device argument is the pathname of the block device.

WARNING: All data in the discarded region on the device will be lost!

The command is there since Ubuntu 15.04 and OpenSUSE 13.1 (yes OpenSUSE has it 2 years ahead of Ubuntu).

Tankman六四
  • 1,681
  • 2
  • 18
  • 23
  • thx for adding information to this outdated post and welcome to askubuntu. – mondjunge Sep 30 '13 at 10:03
  • Arch Linux already has this package as util-linux 2.23 was released on 25 April 2013. – Lekensteyn Sep 30 '13 at 15:26
  • 6
    Thanks for the welcome. Outdated post? Old, but not outdated, as long as it pops up in 1st page of Google search result, there are always new guys looking for the same answer coming here. To me it is outdated only when better pages push it out of 1st google result page. – Tankman六四 Dec 19 '13 at 04:07
  • For the interested, the various IOCTLs are documented in this blog post: http://rwmj.wordpress.com/2014/03/11/blkdiscard-blkzeroout-blkdiscardzeroes-blksecdiscard/ – Lekensteyn Nov 07 '14 at 10:34
  • 7
    If you are wondering the difference between blkdiscard and the hdparm command, it is answered here: "When you use blkdiscard, the SSD (assuming a SATA SSD) will receive an ATA TRIM command, whereas hdparm --security-erase will issue an ATA SECURITY ERASE UNIT command. What the drive then actually does is dependant on the implementation details of that particular SSD's firmware." – Lekensteyn Dec 06 '14 at 14:06
  • Note: This does not seem to work over USB. – loxo Feb 06 '15 at 08:50
  • 5
    You actually don't want to use blkdiscard. First, it is intended to inform the drive that specific parts of it may be thrown out, not to wipe the whole thing. The drive may or may not actually erase the data. The secure erase command must erase all data, including any data that is in parts of the drive that are not currently accessible. Edit: just re-read the question and realized it did not require erasure, but it is still worth noting. – psusi Sep 11 '15 at 00:41
  • 1
    Note for this to work as expected (the device returning zero-bytes after the TRIM, instead of arbitrary data), I suspect the SSD must support the Deterministic Read Zero after TRIM (RZAT) feature (check for it using hdparm -I /dev/sdb | grep 'Deterministic read ZEROs after TRIM'). Some of my SSDs support it but relatively recent Samsung 850 EVO doesn't. Continuing ... – nh2 May 06 '18 at 16:41
  • 2
    ... This post shows that despite the RZAT spec, "TRIM [as a whole] is only advisory, [...] and the device is free to silently ignore all or parts of the request". And Linux does "whitelist drives that are known to reliably return zeroes after TRIM"_. Source in the kernel code. – nh2 May 06 '18 at 16:41
  • Given that the OP's request was “I just need the empty the disk in the most healthy way”, it sounds like blkdiscarding the whole device, then zeroing the first few MiB is the play here, right? Whether or not it actually supports RZAT? – JamesTheAwesomeDude Aug 04 '20 at 22:36
7

If you don't need a secure wipe, why don't you just install kubuntu using the options to 'use entire disk' and the equivalent of 'quick format' (can't remember the exact terminology right now)

That way you ditch the file allocation table and the drive is effectively emptied for overwriting. You don't actually need to empty it.

Rory Alsop
  • 2,789
  • 2
    See http://www.anandtech.com/show/2865/2. Deleting the block is not the same as erasing it and marking it as empty. – Lekensteyn May 12 '11 at 15:48
  • @Lekensteyn Deleting doesn't mean anything for a block device. The installer will call mkfs.ext4 and discard the entire device; this is as secure as a "secure erase", in the sense that in both cases you are trusting the SSD firmware. – Tobu Sep 30 '13 at 11:36
  • 1
    @Tobu Right, that has changed at some point. mkfs.ext4(8) says: discard - Attempt to discard blocks at mkfs time (discarding blocks initially is useful on solid state devices and sparse / thin-provisioned storage). When the device advertises that discard also zeroes data (any subsequent read after the discard and before write returns zero), then mark all not-yet-zeroed inode tables as zeroed. This significantly speeds up filesystem initialization. This is set as default. – Lekensteyn Sep 30 '13 at 15:32
  • @Tobu For my use case, "Secure erase" did not have to really wipe the data from its flash chips, it should just ensure that there are no negative performance effects resulting from having some blocks in use. – Lekensteyn Sep 30 '13 at 15:33
3

If the drive has a Linux filestem on it, you can use fstrim. By default recent Ubuntu runs fstrim on drives from the following vendors: 

    if [ -z "$NO_MODEL_CHECK" ]; then
        if ! contains "$HDPARM" "Intel" && \
           ! contains "$HDPARM" "INTEL" && \
           ! contains "$HDPARM" "Samsung" && \
           ! contains "$HDPARM" "SAMSUNG" && \
           ! contains "$HDPARM" "OCZ" && \
           ! contains "$HDPARM" "SanDisk" && \
           ! contains "$HDPARM" "Patriot"; then
            #echo "device $DEV is not a drive that is known-safe for trimming"
            continue

Once a week.

So one answer to your question is boot up the system and wait a week!

Bryce
  • 1,937
1

Check to see if the BIOS on the computer supports this. On a laptop I just checked, there's an option to do a secure erase of all attached media on the next boot. This is probably a widely used option in corporate environments, so many vendors probably include it now. (I was checking on a Dell Precision 5510 laptop from 2017.)

Though if you just want to wipe the drive to install Linux (as per the question), you don't need to do a full wipe. The only concern is that the drive should know that the space used previously by Windows is now free, to optimize SSD use.

There are many options for this, including those mentioned already. I note that mke2fs has the -E discard option that should trim the partition when creating the file system, which is enabled by default. (Note that this is the best effort option, so it will silently ignore it if the hardware doesn't support it.) So in most cases you can simply ignore the problem, install Linux, and the installation process will do all the cleanup you need.

MarianD
  • 1,028
Preston Crow
  • 11
-6

Just remove the partition, you do not have to clear the whole disk, old data will be overwritten when the storage is needed for something else.

To enable TRIM:

gksudo gedit /etc/fstab

Change "ext4 errors=remount-ro 0" into "ext4 discard,errors=remount-ro 0". (Add discard)

Save and reboot, TRIM should now be enabled.

Check if TRIM is enabled:

sudo -i
dd if=/dev/urandom of=tempfile count=100 bs=512k oflag=direct
hdparm --fibmap tempfile

Use the first begin_LBA address.

hdparm --read-sector [begin_LBA] /dev/sda

Now it should return numbers and characters. Remove the file and sync.

rm tempfile
sync

Now, run the following command again. If it returns zeros TRIM is enabled.

hdparm --read-sector [begin_LBA] /dev/sda
Alex
  • 217
  • 4
    You do NOT want to fill an SSD with zeros as it will write to every erase block, causing more wear and tear, and leaving every erase block full. Also many drives do NOT immediately zero trimmed sectors. – psusi May 12 '11 at 15:06
  • Sure, it requires many writes, but it does not damage the disk. I have used an Corsair F120 for 10-11 months now and have frequently filled it with zeros. (Doing it before every benchmark) So, after 30-35 times the performance is still the same.(~285MB read, 275MB/write) SMART says: The disk is healthy – Alex May 12 '11 at 15:26
  • 12
    Alex, every single write to an SSD damages it slightly. Writing to every single erase block causes them all to be marked in use, which will prevent the drive's GC from functioning properly and performance will suffer. You can think of it as a whole drive unTRIM. – psusi May 12 '11 at 18:52
  • It's not particularly significant that the SSD was still healthy after 30 rewrites. Recent Samsung SSDs for example have a warranty that expires after TBW equal to 200-600 times the size of the disk. So you'd need to test zeroing the disk a few hundred times before saying it doesn't wear out the disk. Of course you could also retort that if you just do it once then it's probably not such a big damage. – Nemo Jun 05 '23 at 13:31