Announcement

Collapse
No announcement yet.

Ubuntu Aims To TRIM SSDs By Default

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

  • molecule-eye
    replied
    Exactly what are they discussing? It seems like a no-brainer that they ought add a daily cron job by default for supported drives.

    Leave a comment:


  • blackout23
    replied
    Originally posted by Bucic View Post
    Does e.g. Fedora or Arch have TRIM enabled by default?
    You make your own /etc/fstab on Arch and the wiki recommends setting "discard" as mount option with SSDs.

    Leave a comment:


  • randomizer
    replied
    Originally posted by blackout23 View Post
    You are basically never going to write your SSD to death.
    I'm really not sure why there is such paranoia about SSDs. People do everything they can to reduce writes. Has everyone forgotten how catastrophically a spinner can go out? Does nobody realise that if you move your swap to a HDD then you're both reducing performance (particularly on Windows where swap is used all the time) and simply substituting wear on one drive with wear on another?

    Leave a comment:


  • Bucic
    replied
    Does e.g. Fedora or Arch have TRIM enabled by default?

    Leave a comment:


  • DanaG
    replied
    My workplace-provided laptop has a SanDisk Sandforce SSD that just plain LOCKS UP upon large TRIM operations. I've just given up on having TRIM enabled on the thing.

    I hope Canonical will document this some way, so anyone with drives that behave this badly will know to blame the drive, not Ubuntu.

    Leave a comment:


  • jwilliams
    replied
    Originally posted by grege View Post
    but @jwilliams you seem to be very anti SSD.
    Quite the opposite. I own many SSDs and I am highly satisfied with their performance and reliability.

    Leave a comment:


  • grege
    replied
    More on SSDs

    We are getting more off topic here, but @jwilliams you seem to be very anti SSD. Once I used my first one I could never go back. I have a Mini-ITX machine with an Intel i3-2120 and an OCZ 256GB SSD running Arch with Gnome 3.10 and a 3.12 kernel. The longest part of the boot process is me typing in my password and shutdown takes about 5 seconds. Big programs like LibreOffice Writer open almost instantly. And the box rarely uses more than 26w and it is very quiet (the only moving part is the CPU fan). I have never had any issue with the SSDs. My first system was an SSD boot drive (/), with swap and /home on a second HDD - fast enough for most people, but since then I just have an SSD and lay off data storage to my NAS.

    Failures do occur (so far not to me), but then I have had a few HDDs fail as well. I do back up important data to a NAS, but then I did that in the olden days of HDDs as well. A friend of mine recently had an early OCZ SSD die after just less than three years, and he did not even consider going back to an HDD. He got a new drive and restored his disk clone and went on his merry way.

    Just my opinion as a very happy SSD user.

    Leave a comment:


  • blackout23
    replied
    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.

    http://www.xtremesystems.org/forums/...e-25nm-Vs-34nm

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

    Leave a comment:


  • jwilliams
    replied
    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.

    Leave a comment:


  • grege
    replied
    That should have been The Tech Report

    http://techreport.com/review/25559/t...t-200tb-update

    Leave a comment:

Working...
X