Bug 846949 - TRIM doesn't work on EXT4
TRIM doesn't work on EXT4
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel (Show other bugs)
6.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Red Hat Kernel Manager
Red Hat Kernel QE team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-09 04:40 EDT by Mykola Ulianytskyi
Modified: 2012-08-09 23:11 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-09 21:28:56 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mykola Ulianytskyi 2012-08-09 04:40:11 EDT
Description of problem:
TRIM doesn't work on EXT4

Version-Release number of selected component (if applicable):
kernel-2.6.32-279.2.1.el6.x86_64

How reproducible:
Always


/etc/fstab:
UUID=ea113042-48a8-4ca7-9b12-2d147ec0adf9  /            ext4    defaults,noatime,nodiratime,discard        1 1

# hdparm -I /dev/sda | grep -i trim
* Data Set Management TRIM supported (limit 8 blocks)

# smartctl -i /dev/sda | grep Model
Device Model:     Corsair Performance Pro


TEST TRIM:
1. Create test file

# seq 1 1000 > testfile
# sync

2. Read sector

# hdparm --fibmap testfile
 filesystem blocksize 4096, begins at LBA 63; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0   46403743   46403750          8

# hdparm --read-sector 46403743 /dev/sda
reading sector 46403743: succeeded
0a31 0a32 0a33 0a34 0a35 0a36 0a37 0a38
...

3. Remove file

# rm -f testfile
# sync
# sleep 10

4. Verify TRIM:
# hdparm --read-sector 46403743 /dev/sda

/dev/sda:
reading sector 46403743: succeeded
0a31 0a32 0a33 0a34 0a35 0a36 0a37 0a38
...

Result: TRIM doesn't work. All values should be zeros:
reading sector 46403743: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
...


fstrim doesn't TRIM data too (values are not zeros).

# fstrim -v /
/: 90123654612 bytes were trimmed

# fstrim -v /
/: 0 bytes were trimmed



Test TRIM howtos with screenshots:
* http://nedoboi.wordpress.com/2011/11/12/tiny-tips-ssd-and-linux-enable-trim-and-check-if-it-works/
* http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/2

Has anybody had this problem or TRIM clean data as expected?

kernel-ml-3.5.0-2.el6.elrepo.x86_64 from ELrepo doesn't fix the problem.
Comment 2 Ric Wheeler 2012-08-09 13:00:43 EDT
If you want to verify TRIM, you need to be consistent in which level you test at (block level using hdparm or via the file system).

Also note that the behavior of each device can vary - TRIM commands can be ignored by a target.

If you are a RH customer, please open an official support ticket so we can track and escalate properly.

If you don't have a RH support contract, I would suggest taking this report to linux-ext4 mailing list or possible linux-ide@vger.kernel.org.
Comment 3 Mykola Ulianytskyi 2012-08-09 14:01:31 EDT
Hi, Ric

It seems to be the SSD firmware bug.

I just tested other SSD PLEXTOR PX-256M3 with the same Marvell chipset - TRIM works perfectly on RHEL kernel and on vanilla kernel 3.5.

Thank you
Comment 4 Mykola Ulianytskyi 2012-08-09 14:02:28 EDT
Please close as not_a_bug.
Comment 5 Ric Wheeler 2012-08-09 21:28:56 EDT
Hi Nikolay,

Please note that the specification has various options in it - devices have a specific option to return "0" or not for trimmed regions (not sure if Martin Peterson's doc covers this, but have a look in google for linux-advanced-storage-6.0.pdf for some details).

The device might be compliant with the spec and return you garbage after a TRIM command (although that is not really useful!).

Note You need to log in before you can comment on or make changes to this bug.