Results 1 to 5 of 5

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

  1. #1
    Join Date
    Nov 2011
    Posts
    3

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

    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:

    Code:
    /dev/sda2 / ext4 rw,noatime,errors=remount-ro,user_xattr,acl,barrier=1,stripe=128,discard 0 0
    ioscheduler is noop:
    Code:
    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:
    Code:
    $ 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
    Last edited by Lem98; 11-04-2011 at 12:53 PM.

  2. #2
    Join Date
    Nov 2011
    Posts
    3

    Default

    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.

  3. #3

    Default

    Quote Originally Posted by Lem98 View Post
    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.

  4. #4
    Join Date
    Nov 2011
    Posts
    3

    Default

    Quote Originally Posted by AnonymousCoward View Post
    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:

    Code:
    hdparm --read-sector [sector] /dev/sda
    or with dd.

    I had found the sector using:

    Code:
    hdparm --fibmap file
    or:

    Code:
    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

  5. #5

    Default

    Quote Originally Posted by Lem98 View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •