Announcement

Collapse
No announcement yet.

Ubuntu Aims To TRIM SSDs By Default

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

  • Ubuntu Aims To TRIM SSDs By Default

    Phoronix: Ubuntu Aims To TRIM SSDs By Default

    During the first day of the latest virtual Ubuntu Developer Summit, Canonical developers plotted out the enabling of TRIM/DISCARD support by default for solid-state drives on Ubuntu...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Wow. About time ehh?

    Comment


    • #3
      Originally posted by blackout23 View Post
      Wow. About time ehh?
      Yeah... Windows 7 was released in 2009 with trim support?

      Comment


      • #4
        Originally posted by Ferdinand View Post
        Yeah... Windows 7 was released in 2009 with trim support?
        Problem is that on Windows 7, NTFS does what the discard option does on the various file-systems that support it. There are cases when fstrim / discard are not considered to be optimal.

        Comment


        • #5
          I did not listen to the whole conference, so I do not know if it was mentioned, but my understanding is that some SSDs are much slower than others at responding after large TRIM commands. I believe some of the people doing SSD flash longevity tests found that certain Sandforce SSDs could be slow for a minute or more after large TRIM commands.

          Comment


          • #6
            Originally posted by jwilliams View Post
            I did not listen to the whole conference, so I do not know if it was mentioned, but my understanding is that some SSDs are much slower than others at responding after large TRIM commands. I believe some of the people doing SSD flash longevity tests found that certain Sandforce SSDs could be slow for a minute or more after large TRIM commands.
            It may be due to Sandforce chips using in-house compression for the data it manipulates, therefore large TRIM commands means large compression/decompression processes.

            Comment


            • #7
              It should be part of the installer

              I am up to my fourth SSD and they all work fine with Arch and Debian. When I got my first one I read a whole lot of HowTos and stuff that are all pretty much way out of date. The modern installer disk partitioners do a perfectly good job of setting them up except for TRIM.

              Why not another dialog to activate TRIM? As in Mount Point, Bootable, Trim etc. It has always seemed silly that you have to manually edit fstab to put in "discard", when TRIM has been supported for many years.

              Off topic but related, Techradar are doing a long term test of SSDs by hammering them all day long. It is very interesting that even after 200Tb of data being written and deleted they are all still fully functional, although some are using a few replacement addresses.

              Comment


              • #8
                That should have been The Tech Report

                Comment


                • #9
                  That techreport SSD longevity test has the same flaw as most others that have been done since this has become trendy. The problem is that they are not testing data retention time. The main reason that the flash in consumer SSDs is specified as having 3000 erase cycles (or whatever number is given) is that once you go beyond that number of erase cycles, the data retention time could fall below 1 year (which is the minimum allowed data retention spec for consumer flash).

                  To test data retention, you have to stop writing (and have recorded the checksums of the last data written), leave the SSD powered off for some time (obviously a year is not practical, but I think at least a week would be a minimum practical time for testing), and then power up the SSD and verify the checksums on the data.

                  With the test techreport has been doing, the data retention time could get down as low as a few hours and they would not even know it. They would think the SSD was still functioning. But very few users would even consider using an SSD with a data retention time of less than 24 hours. Personally, I would not use one with a data retention time of less than a month.

                  Comment


                  • #10
                    Originally posted by grege View Post
                    I am up to my fourth SSD and they all work fine with Arch and Debian. When I got my first one I read a whole lot of HowTos and stuff that are all pretty much way out of date. The modern installer disk partitioners do a perfectly good job of setting them up except for TRIM.

                    Why not another dialog to activate TRIM? As in Mount Point, Bootable, Trim etc. It has always seemed silly that you have to manually edit fstab to put in "discard", when TRIM has been supported for many years.

                    Off topic but related, Techradar are doing a long term test of SSDs by hammering them all day long. It is very interesting that even after 200Tb of data being written and deleted they are all still fully functional, although some are using a few replacement addresses.
                    200TB is nothing. SSDs can take over 1500TB of write performance.

                    Well, we've started the quest to find out how long an SSD can last. I'm using the Kingston SSDNow 40GB, a rebranded Intel X25-V and One_Hertz is using the new 320 Series 40GB SSD. I'll be posting updates every day, well, thats my intention at least :) This is the status of my SSD just before the test started. 114380


                    You are basically never going to write your SSD to death.

                    Comment

                    Working...
                    X