I can't enable TRIM on my newly-installed SSD. Ubuntu Server 12.04, Linux 3.11.0-15-generic. I turned TRIM on through discard setting in /etc/fstab. Also TRIM doesn't work with fstrim command.

Here is how I check if TRIM works or not:

#for i in {1..100000}; do echo "1" >> tempfile; done
#sudo hdparm --fibmap tempfile
#sudo hdparm --read-sector 293865512 /dev/sda
#rm tempfile
#sudo hdparm --read-sector 293865512 /dev/sda

The second run of hdparm --read-sector command should return zeros in case of enabled TRIM, but the result is the same as with the first run of that command.

fstrim command does not work:

#sudo fstrim -v /
/: 0 bytes were trimmed

Here's the result of hdparm -i /dev/sda:

Model=KINGSTON SV300S37A240G, FwRev=520ABBF0, SerialNo=50026B7243004D3E
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=1
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=468862128
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes:  pio0 pio1 pio2 pio3 pio4 
DMA modes:  mdma0 mdma1 mdma2 
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
AdvancedPM=yes: unknown setting WriteCache=disabled
Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7

Here's the result of sudo hdparm -I /dev/sda:


ATA device, with non-removable media
    Model Number:       KINGSTON SV300S37A240G                  
    Serial Number:      50026B7243004D3E    
    Firmware Revision:  520ABBF0
    Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
    Used: unknown (minor revision code 0x0110) 
    Supported: 8 7 6 5 
    Likely used: 8
    Logical     max current
    cylinders   16383   16383
    heads       16  16
    sectors/track   63  63
    CHS current addressable sectors:   16514064
    LBA    user addressable sectors:  268435455
    LBA48  user addressable sectors:  468862128
    Logical  Sector size:                   512 bytes
    Physical Sector size:                   512 bytes
    Logical Sector-0 offset:                  0 bytes
    device size with M = 1024*1024:      228936 MBytes
    device size with M = 1000*1000:      240057 MBytes (240 GB)
    cache/buffer size  = unknown
    Nominal Media Rotation Rate: Solid State Device
    LBA, IORDY(can be disabled)
    Queue depth: 32
    Standby timer values: spec'd by Standard, with device specific minimum
    R/W multiple sector transfer: Max = 16  Current = 1
    Advanced power management level: 254
    DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
         Cycle time: min=120ns recommended=120ns
    PIO: pio0 pio1 pio2 pio3 pio4 
         Cycle time: no flow control=120ns  IORDY flow control=120ns
    Enabled Supported:
       *    SMART feature set
            Security Mode feature set
       *    Power Management feature set
            Write cache
       *    Host Protected Area feature set
       *    WRITE_BUFFER command
       *    READ_BUFFER command
       *    NOP cmd
       *    Advanced Power Management feature set
            Power-Up In Standby feature set
       *    SET_FEATURES required to spinup after power up
            SET_MAX security extension
       *    48-bit Address feature set
       *    Mandatory FLUSH_CACHE
       *    FLUSH_CACHE_EXT
       *    SMART error logging
       *    SMART self-test
       *    General Purpose Logging feature set
       *    64-bit World wide name
       *    IDLE_IMMEDIATE with UNLOAD
            Write-Read-Verify feature set
       *    {READ,WRITE}_DMA_EXT_GPL commands
       *    Segmented DOWNLOAD_MICROCODE
            unknown 119[6]
       *    Gen1 signaling speed (1.5Gb/s)
       *    Gen2 signaling speed (3.0Gb/s)
       *    Gen3 signaling speed (6.0Gb/s)
       *    Native Command Queueing (NCQ)
       *    Phy event counters
       *    NCQ priority information
       *    unknown 76[15]
       *    DMA Setup Auto-Activate optimization
            Device-initiated interface power management
       *    Software settings preservation
       *    SMART Command Transport (SCT) feature set
       *    SCT LBA Segment Access (AC2)
       *    SCT Data Tables (AC5)
       *    reserved 69[3]
       *    DOWNLOAD MICROCODE DMA command
       *    WRITE BUFFER DMA command
       *    READ BUFFER DMA command
       *    Data Set Management TRIM supported (limit 1 block)
    Master password revision code = 65534
    not enabled
    not locked
    not frozen
    not expired: security count
        supported: enhanced erase
Logical Unit WWN Device Identifier: 50026b7243004d3e
    NAA     : 5
    IEEE OUI    : 0026b7
    Unique ID   : 243004d3e
Checksum: correct

Here's dmesg | grep discard:

[    6.417350] EXT4-fs (sda1): re-mounted. Opts: discard,errors=remount-ro
[    6.471628] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: discard

And here's cat /etc/mtab | grep discard:

/dev/sda1 / ext4 rw,noatime,nodiratime,discard,errors=remount-ro 0 0
/dev/sdb1 /home/backup ext4 rw,noatime,nodiratime,discard 0 0

Also I have successfully enabled TRIM through discard on two other computers with the same OS but the different SSD.


I think the major misconception here is that issuing TRIM will cause the blocks to be erased then and there. Really all that the TRIM command is doing is informing the SSD that the OS no longer needs the data at this location, exactly what happens after that is up to the firmware Ideally the firmware should use this information to:

  1. Avoid copying and re-writing this data when another part of the block is rewritten. Remember that the erase block size for an SSD is (always?) larger than the write block size, so when it has to re-write a particular block, it will often have to copy a larger area, erase and re-write the larger area with the updated data included. If a TRIM has been issued for part of that area, this part it does not have to be copied or rewritten. This is faster and prevents unneeded writes which will shorten the life of the device.

  2. Perform other wear levelling optimisations.

Neither of these require that the data be erased straight away. In fact, it may be better for the SSD's lifespan if this doesn't happen when the trimmed area is less than the size of an erase block. That said, it also follows that it may be good practice for the SSD to erase the areas that cover full erase blocks soon after the TRIM is issued.

If you have had success with the above method before, it may have been that the SSDs used had a smaller erase block size. Unfortunately the manufacturers rarely publish this data, but digging around, 512k doesn't seem to be unheard of. You may have success if you try reading and writing a larger area which would cover several erase blocks and reading from the middle of the area rather than the start or end, since the first part may not get its own erase block.

However note that I had the same result as the question even with an 16 MiB continuous block.

  • Thank you very much for such detailed response. I understand that my method of checking TRIM might not be correct. If I check it for a large file about 100MB, the result is the same - after deleting and sync bytes are not erased. Although if I delete tempfile and create the other one with the same size, hdparm says that new file is situated exactly at the place where the old one was. And I'm sure this case bytes belongs to the new file. It seems that TRIM is supported - SSD was informed about unused blocks and has overwritten them. – Kasheftin Apr 11 '14 at 12:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.