Re: SSD drive reliability.

From	David Brown <david.brown@hesbynett.no>
Newsgroups	comp.os.linux.hardware
Subject	Re: SSD drive reliability.
Date	2014-06-18 10:06 +0200
Organization	A noiseless patient Spider
Message-ID	<lnrhaj$giu$1@dont-email.me> (permalink)
References	(5 earlier) <slrnlpcn12.v9h.BobT@linus.cs.queensu.ca> <lnguru$d5t$1@dont-email.me> <lnmak1$o75$1@dont-email.me> <lnp50c$ed7$1@dont-email.me> <op.xhlxnuz0a3w0dxdave@hodgins.homeip.net>

Show all headers | View raw

On 17/06/14 18:34, David W. Hodgins wrote:
> On Tue, 17 Jun 2014 06:24:13 -0400, Charles T. Smith
> <cts.private.yahoo@gmail.com> wrote:
> 
>> So, in conclusion - don't use an SSD if you're going to run linux.
> 
> I've been using an ssd drive as my main drive for 3 years now. I'll
> never go back to using a spinning disk as my main drive, due to the
> speed difference.
> 
> I use opera for wab browsing, email, usenet, and rss feeds. I usually
> have around 30 web tabs open, and have around 100,000 messages for it
> to keep indexed. On a spinning disk, it takes 2 to 3 minutes to fully
> open. On a ssd drive, it's under 15 seconds.
> 
> The one thing I learned the hard way, is that the os must enable the
> trim function for filesystems on an ssd drive, or it will slow down
> to the point it seems like an old floppy drive. I use the script
> http://www.ody.ca/~dwhodgins/autofstrim
> which I've copied to /etc/cron.daily
> 

That is the right way to handle trimming - but your description is a bit
inaccurate.

There are three ways to handle trim on an SSD (on Linux - other OS's are
more limited).  You can ignore it, you can enable a trim mount option
(for ext4 and possibly other systems), or you can use fstrim for offline
trimming.

Ignoring trim is actually a perfectly good solution for modern SSDs of a
reasonable size.  They have good garbage collection, and
overprovisioning means that there are always free blocks on hand.  The
slowdown and extra wear in comparison to a trimmed SSD is very minor or
negligible for many loads.  Older and smaller SSDs get more benefit from
trim.

Online trim using a mount option means that when a filesystem deletes a
file, it immediately sends a trim on the freed blocks.  This makes them
available to the SSD without delay - but because the complete morons who
specified SATA TRIM made it non-queueable and synchronous (instead of
copying the SCSI TRIM commands), a TRIM is a very slow operation that
blocks everything else on the disk.  Thus online TRIM makes many
operations, especially deletes and other metadata changes, significantly
slower.  It is seldom a good solution.

Offline trim using "fstrim" lets you get the benefits of trimming, by
sending TRIM commands for all parts of the partition that are not used
by the filesystem.  It can take a bit of time to run, depending on the
state of the filesystem, as is best done off-peak.  I believe most
distros now install suitable cron jobs by default, or you can have your
own own.

So usually I would recommend "fstrim" or simply ignoring trim (as long
as your disk is reasonably new).  But the phrase "enable the trim
function for the filesystem" implies to me a trim mount, and that is
something you normally want to avoid.

mvh.,

David

> Regards, Dave Hodgins
>

Thread

SSD drive reliability. wexfordpress <john@wexfordpress.com> - 2014-06-09 15:49 -0700
  Re: SSD drive reliability. Bob Tennent <BobT@cs.queensu.ca> - 2014-06-09 23:13 +0000
    Re: SSD drive reliability. Måns Rullgård <mans@mansr.com> - 2014-06-10 00:57 +0100
      Re: SSD drive reliability. Bob Tennent <BobT@cs.queensu.ca> - 2014-06-10 00:54 +0000
        Re: SSD drive reliability. Måns Rullgård <mans@mansr.com> - 2014-06-10 02:01 +0100
          Re: SSD drive reliability. Bob Tennent <BobT@cs.queensu.ca> - 2014-06-10 01:15 +0000
            Re: SSD drive reliability. "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-06-14 07:50 +0000
              Re: SSD drive reliability. Poutnik <poutnik@privacy.net> - 2014-06-14 10:19 +0200
              Re: SSD drive reliability. "Trevor Hemsley" <Trevor.Hemsley@mytrousers.ntlworld.com> - 2014-06-14 21:10 -0500
                Re: SSD drive reliability. "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-06-15 08:48 +0000
              Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-06-16 10:41 +0200
                Re: SSD drive reliability. "Charles T. Smith" <cts.private.yahoo@gmail.com> - 2014-06-17 10:24 +0000
                Re: SSD drive reliability. Måns Rullgård <mans@mansr.com> - 2014-06-17 12:24 +0100
                Re: SSD drive reliability. Richard Kettlewell <rjk@greenend.org.uk> - 2014-06-17 12:44 +0100
                Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-06-17 14:43 +0200
                Re: SSD drive reliability. "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2014-06-17 12:34 -0400
                Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-06-18 10:06 +0200
                Re: SSD drive reliability. "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2014-06-19 16:29 -0400
                Re: SSD drive reliability. Fredrik Jonson <fredrik@jonson.org> - 2014-08-13 09:15 +0000
                Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-08-13 13:09 +0200
                Re: SSD drive reliability. Richard Kettlewell <rjk@greenend.org.uk> - 2014-08-13 12:59 +0100
                Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-08-13 15:52 +0200
      Re: SSD drive reliability. JEDIDIAH <jedi@nomad.mishnet> - 2014-06-09 19:45 -0500
        Re: SSD drive reliability. David Brown <david.brown@hesbynett.no> - 2014-06-10 08:51 +0200
  Re: SSD drive reliability. "Vince Coen" <VBCoen@gmail.com> - 2014-06-10 11:49 +0100

csiph-web