Bug 846949
| Summary: | TRIM doesn't work on EXT4 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Mykola Ulianytskyi <lystor> |
| Component: | kernel | Assignee: | Red Hat Kernel Manager <kernel-mgr> |
| Status: | CLOSED NOTABUG | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.3 | CC: | rwheeler |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-08-10 01:28:56 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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.org. 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 Please close as not_a_bug. 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!). |
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.