Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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:
    [email protected]:~$ 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, 12:53 PM.

  • #2
    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.

    Comment


    • #3
      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.

      Comment


      • #4
        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

        Comment


        • #5
          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.

          Comment

          Working...
          X