SanDisk Extreme 480 GB: TRIM not working

SSD (Solid State Drives) All Other SanDisk SSD
1

I just checked my SanDisk Extreme 480 GB SSD and it is already at firmware R201.

But, this drive just refuses to perform TRIM(discard).

I’ve verified in everyway possible that the drive supports TRIM but no TRIM ever takes place.

Even fstrim in Linux fails on any mountpoint on the SSD.

It appears that even the R201 firmware is still not enabling the TRIM(discard) command on this 480 GB drive.

I have another SanDisk Extreme 240 GB drive in another Linux machine and it supports TRIM(discard) just fine but not this 480 GB drive for some reason.

.

2

I have the same issue on my 120GB Extreme.

OS: Linux Ubuntu 12.04

FW on disk: R201 (should be the newest?)

Mount options: rw,noatime,nodiratime,errors=remount-ro,user_xattr,barrier=1,data=ordered,discard

AHCI selected in BIOS, driver active

fstrim also doesn’t do anything…

Oh, what to do?

3

Did you try the 480gig SSD in the other machine where the 240gig SSD was working fine with trim? (on the same controller)

4

Ok, this problem may be related to the SSD being attached to a Marvell 9128 controller.

This controller does not appear to be passing the TRIM command.

I’ve written to the motherboard maker about the problem.

Maybe they need to stop using Marvell controllers?

.

5

Do you think this is related to the LSI SandForce 5 series firmware?  See

http://www.tweaktown.com/articles/4870/lsi_sandforce_5_series_ssd_firmware_trim_lost_and_found_performance_investigated/index.html

6

So I’m coming back to this problem 2 years later.

I’ve moved the SanDisk Extreme 480 to a laptop running Linux (fedora).

I updated the firmware to R211.

smartctl -a /dev/sda | head

smartctl 5.42 2011-10-20 r3458 [x86_64-linux-3.7.3-101.fc17.x86_64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model: SanDisk SDSSDX480GG25
Serial Number: XXXXXXXXXXXXXXXXX
LU WWN Device Id: 5 001b44 78eabe2f0
Firmware Version: R211
User Capacity: 480,103,981,056 bytes [480 GB]
Sector Size: 512 bytes logical/physical

But again I see the same problem - TRIM is not working.

Here’s how I’ve been testing TRIM:

seq -f “%03.0f” 0 999 > /boot/testfile

df /boot/testfile

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 495844 130162 340082 28% /boot

filefrag -s -v /boot/testfile

Filesystem type is: ef53
Filesystem cylinder groups is approximately 61
File size of /boot/testfile is 4000 (4 blocks, blocksize 1024)
ext logical physical expected length flags
0 0 15369 3 merged
1 3 15372 1 merged,eof

dd bs=1024 skip=15369 count=1 if=/dev/sda1 | hexdump -C | head

1+0 records in
1+0 records out
1024 bytes (1.0 kB) copied, 0.000316114 s, 3.2 MB/s
00000000 30 30 30 0a 30 30 31 0a 30 30 32 0a 30 30 33 0a |000.001.002.003.|
00000010 30 30 34 0a 30 30 35 0a 30 30 36 0a 30 30 37 0a |004.005.006.007.|
00000020 30 30 38 0a 30 30 39 0a 30 31 30 0a 30 31 31 0a |008.009.010.011.|
00000030 30 31 32 0a 30 31 33 0a 30 31 34 0a 30 31 35 0a |012.013.014.015.|
00000040 30 31 36 0a 30 31 37 0a 30 31 38 0a 30 31 39 0a |016.017.018.019.|
00000050 30 32 30 0a 30 32 31 0a 30 32 32 0a 30 32 33 0a |020.021.022.023.|
00000060 30 32 34 0a 30 32 35 0a 30 32 36 0a 30 32 37 0a |024.025.026.027.|
00000070 30 32 38 0a 30 32 39 0a 30 33 30 0a 30 33 31 0a |028.029.030.031.|
00000080 30 33 32 0a 30 33 33 0a 30 33 34 0a 30 33 35 0a |032.033.034.035.|
00000090 30 33 36 0a 30 33 37 0a 30 33 38 0a 30 33 39 0a |036.037.038.039.|

rm /boot/testfile

rm: remove regular file `/boot/testfile’? y

sync

fstrim -v /boot

/boot: 1907712 bytes were trimmed

dd bs=1024 skip=15369 count=1 if=/dev/sda1 | hexdump -C | head

1+0 records in
1+0 records out
1024 bytes (1.0 kB) copied, 3.7879e-05 s, 27.0 MB/s
00000000 30 30 30 0a 30 30 31 0a 30 30 32 0a 30 30 33 0a |000.001.002.003.|
00000010 30 30 34 0a 30 30 35 0a 30 30 36 0a 30 30 37 0a |004.005.006.007.|
00000020 30 30 38 0a 30 30 39 0a 30 31 30 0a 30 31 31 0a |008.009.010.011.|
00000030 30 31 32 0a 30 31 33 0a 30 31 34 0a 30 31 35 0a |012.013.014.015.|
00000040 30 31 36 0a 30 31 37 0a 30 31 38 0a 30 31 39 0a |016.017.018.019.|
00000050 30 32 30 0a 30 32 31 0a 30 32 32 0a 30 32 33 0a |020.021.022.023.|
00000060 30 32 34 0a 30 32 35 0a 30 32 36 0a 30 32 37 0a |024.025.026.027.|
00000070 30 32 38 0a 30 32 39 0a 30 33 30 0a 30 33 31 0a |028.029.030.031.|
00000080 30 33 32 0a 30 33 33 0a 30 33 34 0a 30 33 35 0a |032.033.034.035.|
00000090 30 33 36 0a 30 33 37 0a 30 33 38 0a 30 33 39 0a |036.037.038.039.|

And as you can see - no TRIM occurred.

.

7

There are a few different kinds of TRIM.

  • Deterministic Read Zero after Trim (DZAT): all read commands to the LBA after a Trim shall return zero
  • Non-deterministic Trim: each read command to the LBA after a Trim may return different data
  • Deterministic Trim (DRAT): all read commands to the LBA after a Trim shall return the same data, or become determinate.

Since after running TRIM you are seeing the same data it seems the Extreme SSD implements DRAT TRIM. Returning the same data after TRIM does not mean that TRIM is not working it only means it is a DRAT implementation. 

8

I have run trim commands on other SSD’s and always the underlying block bytes went to zeroes.

In fact this happens with this same SanDisk Extreme series in the 240.

But the 480 just refuses to erase.

.

9

Still it is most likely using DRAT TRIM. different capacities could have different implementation. Regardless it is really a moot point. The Extreme has been EOL for quite some time and no new FW updates in quite a while. 

10

It’s not a moot point.  The drive is still under warranty and doesn’t work as advertised.  The drive is supposed to have TRIM support.  But at least in this drive it doesn’t work.

11

it is likely using DRAT TRIM the drive will return the same data after TRIM. TRIM is working just not the implementation you are testing for.