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
#sync
#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:
/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
Standards:
Used: unknown (minor revision code 0x0110)
Supported: 8 7 6 5
Likely used: 8
Configuration:
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
Capabilities:
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
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
Write cache
Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* NOP cmd
* DOWNLOAD_MICROCODE
* 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
* WRITE_{DMA|MULTIPLE}_FUA_EXT
* 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
* SET MAX SETPASSWORD/UNLOCK DMA commands
* WRITE BUFFER DMA command
* READ BUFFER DMA command
* Data Set Management TRIM supported (limit 1 block)
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
supported: enhanced erase
4min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
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.
Best Answer
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:
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.
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.