I am no guru, so I cannot speak in regard to the design decisions regarding this, but you can always test to see if discard is working.
I have TRIM enable by fstab, my SSD suports it.
I tryed what the web (nodoboi) says but I can no see the 00 00 00...
Can anybody help?
I currently don't have time to change the WIKI, so you're welcome to do it ;-)
]]>tune2fs -o discard
...
it is working flawlessly. I think I may turn this option on with all my ssd partitions. Maybe also get some noatime up in this sh*t!Edit: It no likey my attempts to add noatime. I guess that is not meant to be set this way.
I finally got a chance to test it myself and my results are the same as yours. It is working just fine even though mount isn't showing the discard option in its output.
As for turning on noatime via tune2fs, this one doesn't seem to be listed among the supported mount options. See man tune2fs, the -o option.
All this is valuable info and should make it to the SSD wiki. I don't have time for it at the moment, but I'll see what I can do if nobody else decides to chip in.
]]>$ mount -l
...
/dev/sdb5 on /mnt type ext4 (rw,noatime,data=ordered)
...
As you can see, no indication that trim is present or on.
Here is after I wrote a file
hdparm --read-sector 168866824 /dev/sdb
/dev/sdb:
reading sector 168866824: succeeded
3031 3030 2031 6574 7473 6c20 6e69 0a65
3031 3030 2032 6574 7473 6c20 6e69 0a65
3031 3030 2033 6574 7473 6c20 6e69 0a65
3031 3030 2034 6574 7473 6c20 6e69 0a65
3031 3030 2035 6574 7473 6c20 6e69 0a65
3031 3030 2036 6574 7473 6c20 6e69 0a65
3031 3030 2037 6574 7473 6c20 6e69 0a65
...
...and here is after I deleted the file
hdparm --read-sector 168866824 /dev/sdb
/dev/sdb:
reading sector 168866824: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
...
As you can see it is working flawlessly. I think I may turn this option on with all my ssd partitions. Maybe also get some noatime up in this sh*t!
Edit: It no likey my attempts to add noatime. I guess that is not meant to be set this way.
]]>I am no guru, so I cannot speak in regard to the design decisions regarding this, but you can always test to see if discard is working.
This was helpful; thanks.
To summarize it for others reading this thread: testing is done by creating a file, checking its sector ranges and contents on disk with hdparm --fibmap and --read-sector, then deleting the file and checking sectors again. After a successful TRIM, deleted data should be zeroed out.
According to a discussion on redhat linux-lvm and another on centos hardware support, the above depends on the SSD TRIM implementation. (Look for Deterministic read data after TRIM or Deterministic read ZEROs after TRIM in hdparm -I output.)
But here's another significant (confirmed) discovery I've made: TRIM doesn't immediately work on ext4 without a journal. It works when manually invoking the fstrim command though. After adding the journal back, deleted files followed by sync were promptly zeroed out as expected.
]]>As the OP, I also noticed that after setting 'discard' as one of the default mount options with 'tune2fs' directly on ext4, 'mount' will not show it as being used:
# tune2fs -o discard /dev/sda2
# tune2fs -l /dev/sda2 | grep discard
Default mount options: user_xattr acl discard
# grep discard /etc/fstab
LABEL=archlinux-ssd / ext4 defaults,noatime,discard 0 1
# mount | grep sda2
/dev/sda2 on / type ext4 (rw,noatime,data=ordered)
But when that fs option is cleared, everything looks good after mounting via fstab:
# tune2fs -o^discard /dev/sda2
# mount | grep sda2
/dev/sda2 on / type ext4 (rw,noatime,discard,data=ordered)
I got curious and spent some time researching this and found an acceptable answer on gmane.comp.file-systems.ext4.
In essence, default mount options for the fs are just not shown by design. Thus, in my case I couldn't see 'user_xattr', 'acl' and 'discard' but I *think* they were active and working.
Any input on this from the kernel/fs gurus?
]]>dmesg | grep discard
/dev/sda3 on / type ext4 (rw,noatime,user_xattr,barrier=1,data=ordered,discard)
Only setting via fstab.
]]>UUID=718af3d3-8622-4126-a539-e07ba9aa84c6 /home ext4 defaults,noatime,discard 0 1
UUID=7e4badd1-13d7-4dda-9820-81958495e476 /var ext4 defaults,noatime,discard 0 1
UUID=91c98608-2fc6-4346-a60e-3dd1ced19ef0 /boot ext4 defaults,noatime,discard 0 1
UUID=9e0dbe1c-070e-4fd8-a2c7-6d82a3a31ca7 / ext4 defaults,noatime,discard 0 1
UUID=a6e5c6bd-f428-4182-9c0e-88a4b767117d /tmp ext4 defaults,noatime,discard 0 1
tmpfs /tmp tmpfs nodev,nosuid,noatime 0 0
tmpfs /var/tmp tmpfs defaults,noatime 0 0
tmpfs /var/lock tmpfs defaults,noatime 0 0
tmpfs /var/run tmpfs defaults,noatime 0 0
tmpfs /home/markus/.thumbnails tmpfs defaults,noatime 0 0
tmpfs /home/markus/.cache tmpfs defaults,noatime 0 0
reboot and check if the partition is mounted with the discard option: cat /etc/mtab | grep discard
]]>i'd report it as a bug somewhere, but i don't know where. is that kernel code?
]]>Dunno what to tell you; I didn't mess with tune2fs to enable it, just made the entries in the fstab. You sure your SSD supports it?
It's a fairly new OCZ agility 3, I think it supports it.
I removed the discard option with tune2fs, now the mount says it is mounted with discard. So basically, problem solved - but WHY did it not work? is it a bug?
$ grep discard /etc/fstab
/dev/disk/by-label/arch64 / ext4 defaults,noatime,discard 0 1
/dev/disk/by-label/homes /home ext4 defaults,noatime,discard 0 2
$ mount | grep discard
/dev/sdb1 on / type ext4 (rw,noatime,user_xattr,acl,barrier=1,data=ordered,discard)
/dev/sdb2 on /home type ext4 (rw,noatime,user_xattr,acl,barrier=1,data=ordered,discard)