Ext4 discard option (AKA TRIM) not working on SSD Crucial M4 64GB

[Lem98]

OS: Ubuntu Oneiric 64bit, fresh install, kernel 3.0.0.12.

SSD: Crucial M4 64GB

AHCI enabled in BIOS

/dev/sda2 (my / ) is an ext4 filesystem created without journal, mounted with noatime,discard options. /proc/mounts confirms:

/dev/sda2 / ext4 rw,noatime,errors=remount-ro,user_xattr,acl,barrier=1,stripe=128,discard 0 0

ioscheduler is noop:

lem@biggy:~$ cat /sys/block/sda/queue/scheduler
[noop] deadline cfq

So: "discard TRIMMING" is not working - double checked this way: http://andyduffell.com/techblog/?p=852

However if I manually run:

$ sudo fstrim -v /

(remember: /dev/sda2 is mounted on / )
in a few seconds I get my device trimmed, and then I can see my zeroes on it.

I know that years ago there was a problem with discard and no journal (patch required):
http://kerneltrap.org/mailarchive/li...0/5/13/6884480, but I hope this is no more the case...

Am I the only one?
What's going on?

Thanks for any suggestions.

--
Bye, Lem

[Lem98]

OK, I've got some feedback elsewhere, and I made myself some tests.

"Discard" mount option does NOT work with an ext4 filesystem, if it doesn't have a journal. It works with a journal, instead.

However, "fstrim" command works even without a journal.

What is really bad, IMHO, is that, when they work, every byte which is trimmed (AKA discarded) is immediately reset (AKA deleted) by my Crucial M4 firmware (ver. 02) even if it wouldn't be necessary (almost empty page in an almost empty block in an almost empty disk): which means a lot of unnecessary resets (every reset means that a whole block of 512kB loses one of its lives).

I don't know if this happens because of the discard/trim implementation in ext4, or because the firmware of my Crucial M4 (ver. 02) is *stupid*.

Bye, Lem.

[AnonymousCoward]

What is really bad, IMHO, is that, when they work, every byte which is trimmed (AKA discarded) is immediately reset (AKA deleted) by my Crucial M4 firmware (ver. 02) even if it wouldn't be necessary (almost empty page in an almost empty block in an almost empty disk): which means a lot of unnecessary resets (every reset means that a whole block of 512kB loses one of its lives).

Are you sure the blocks are actually written to? Trim should just mark them as empty, and reading them will return zeroes, but the flash itself shouldn't be touched. Unless you have low-level access to the flash itself (and not just the mapping to a device the controller gives you), I don't think you can actually check the behaviour yourself.

[Lem98]

Are you sure the blocks are actually written to? Trim should just mark them as empty, and reading them will return zeroes, but the flash itself shouldn't be touched. Unless you have low-level access to the flash itself (and not just the mapping to a device the controller gives you), I don't think you can actually check the behaviour yourself.

This is interesting! Thanks for your reply. So:

a) if I don't see zeroes, trim/discard is not working;
b) if I see zeroes, trim has worked, but I cannot know whether those zeroes come from the flash itself or are faked by the firmware.

Did I get it?
I didn't know that the SSD firmware would fake the flash content in this spot - ah, damned liar it is! - but it would make sense!

I checked with:

hdparm --read-sector [sector] /dev/sda

or with dd.

I had found the sector using:

hdparm --fibmap file

or:

debugfs /dev/sda2
  stat file

Anyway I can never know more than the firmware wants to tell me. If it wants to feign...

Thanks again. I feel better now.
--
Bye, Lem

[AnonymousCoward]

a) if I don't see zeroes, trim/discard is not working;
b) if I see zeroes, trim has worked, but I cannot know whether those zeroes come from the flash itself or are faked by the firmware.

Sounds about right. Since the whole point of trim is not to write to the cells, when trim works the controller won't do anything to the flash, and at this point the makers should have figured out how to do trim right.