Re: SSD drive reliability.

From	David Brown <david.brown@hesbynett.no>
Newsgroups	comp.os.linux.hardware
Subject	Re: SSD drive reliability.
Date	2014-08-13 13:09 +0200
Organization	A noiseless patient Spider
Message-ID	<lsfh13$mr1$1@dont-email.me> (permalink)
References	(7 earlier) <lnmak1$o75$1@dont-email.me> <lnp50c$ed7$1@dont-email.me> <op.xhlxnuz0a3w0dxdave@hodgins.homeip.net> <lnrhaj$giu$1@dont-email.me> <slrnlumb5u.kqo.fredrik@biggles.jonson.org>

Show all headers | View raw

On 13/08/14 11:15, Fredrik Jonson wrote:
> In <lnrhaj$giu$1@dont-email.me> David Brown wrote:
>  
>>  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.
> 
> Sorry for reviving an old thread but the TRIM command is queuable nowdays.  A
> queued trim command was introduced in Sata 3.1 and is supported in the linux
> kernel as of version 3.12. So the old advice to avoid online trim because it
> is non-queued should not be relevant any more.
> 
> http://en.wikipedia.org/wiki/Trim_(computing)
> 
> Note that there may be other reasons to not use online trim such as disk
> encryption and buggy ssd firmware.
> 

That's useful information.  Of course, we have to wait for Sata 3.1
motherboards/controller boards, and Sata 3.1 drives to take advantage of
it.  But otherwise it's good to see that horrendously stupid rush-job
Sata TRIM is finally half-fixed.

The other fix (which may be in the Sata 3.1 specs - I haven't bought
them to look) would be to specify that a trimmed block reads as all
zeros.  At the moment, some drives return zeros, some return the old
data, some return whatever happened to be in the drive's cache, and some
might return data that is logically in another part of the disk.  This
all has two problems - one is data security, and the other is that it is
a wasted opportunity for disk formatting and for raid.  If returning
zeros for read of a trimmed block were mandated, initialising and
synchronising a new raid array would be done with a couple of trim commands.

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