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:

          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?

  • Good question, maybe it's enough to just delete the NTFS filesystem?
    – htorque
    May 12, 2011 at 14:11
  • 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, 2011 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, 2011 at 15:04
  • 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, 2011 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? Jun 12, 2011 at 19:25

6 Answers 6


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


  • /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.

  • 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, 2011 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, 2011 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, 2011 at 15:59
  • 1
    What is the reason for recommending secure erase rather than --trim-sector-ranges?
    – kasperd
    Oct 12, 2015 at 9:09
  • 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, 2015 at 18:56

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):


blkdiscard - discard sectors on a device


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


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).

  • 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. Dec 19, 2013 at 4:07
  • 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 6, 2014 at 14:06
  • 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, 2015 at 0: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 6, 2018 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 6, 2018 at 16:41

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.

  • 2
    See anandtech.com/show/2865/2. Deleting the block is not the same as erasing it and marking it as empty.
    – Lekensteyn
    May 12, 2011 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, 2013 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, 2013 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, 2013 at 15:33

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"

Once a week.

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

  • 1
    fstrim is mentioned in this blkdiscard post, you can also invoke it manually with sudo fstrim / (where / is a mountpoint of a filesystem that supports the discard option).
    – Lekensteyn
    Dec 6, 2014 at 14:02

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.


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

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

hdparm --read-sector [begin_LBA] /dev/sda
  • 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, 2011 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, 2011 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, 2011 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 5, 2023 at 13:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .