Re: SSD optimization on Debian (2014)
On Thu, 10 Jul 2014, Jochen Spieker wrote:
> Henrique de Moraes Holschuh:
> > On Wed, 09 Jul 2014, Jochen Spieker wrote:
> >>> * The "discard" options is not needed if your SSD has enough
> >>> overprovisioning (spare space) or you leave (unpartitioned) free
> >>> space on the SSD.
> >>> See http://www.spinics.net/lists/raid/msg40866.html
> >>
> >> AFAIU, this discussion only relates to "online trim" (using the
> >> "discard" mount option). Running an occasional fstrim on your
> >> filesystems is almost free and, apart from RAID issues, I don't see any
> >> negative consequences. Am I missing something?
> >
> > Yes. Broken TRIM implementations, and with a recent kernel, broken QUEUED
> > TRIM implementations.
>
> Are you referring to this?
>
> http://forum.crucial.com/t5/Solid-State-Drives-SSD/M500-M5x0-QUEUED-TRIM-data-corruption-alert-mostly-for-Linux/td-p/151028
Yes. But if you're a Crucial/Micron M500/M550 user, it is better to pay
attention to:
https://bugzilla.kernel.org/show_bug.cgi?id=71371
This sort of problem is nothing new. Back when the non-queued version of
TRIM was introduced, people lost data as well to bad firmware.
Crucial/Micron is not the only ones which will get it wrong. That reminds
me that we need a way to disable queued-trim without disabling NCQ entirely
in Linux, currently you have to patch the kernel to do that.
> I am a little surprised that I didn't read about that earlier. But then
> I don't have any Crucial SSDs.
And I escaped it only because I am sticking to 3.10.x. :-)
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: