On Dec 18, 2013, at 11:50 AM, Robert Moskowitz <r...@htt-consult.com> wrote:
>
> On 12/18/2013 01:32 PM, Chris Murphy wrote:
>>
>> On Dec 18, 2013, at 6:03 AM, Robert Moskowitz <r...@htt-consult.com> wrote:
>>
>>>
>>> On 12/18/2013 04:41 AM, John Obaterspok wrote:
>>>> Hello,
>>>>
>>>> I'm going to setup F20 with a new SSD disk (256gb Samsung 840 PRO) and was
>>>> wondering about best practices for Over Provisioning during partitioning.
>>>
>>> hmmm. I just ordered a Crucial M500 256GB SSD for my new install. I
>>> thought I would have it all to work with (currently using a 320GB HD, so
>>> that is a 64GB reduction already). Are you implying here that you need to
>>> not use all of the SSD drive so that it has some swap around?
>>>
>>> I chose the M500 over the 840 based on price and reviews. The M500 uses
>>> MLC NAND compared to the 840 using TLC NAND.
>>
>> FYI, be aware there appears to be a queued TRIM bug with the M500 where it
>> may be causing silent data corruption. I wouldn't use discard on this, or
>> any, SSD, in production until it's been well tested.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1024002
>
> Seems like a workaround was posted yesterday? So since I am still waiting
> for the drive to show up on my porch…
Yes. Although I'm uncertain whether we get queued TRIM "for free" with a SATA
rev 3.0 controller, or if that means such drives use the SATA rev 3.0
non-queued TRIM? I'm under the impression that to get SATA rev 3.1 queued TRIM
that the drive and the controller it plugs into, and libata all need to support
SATA rev 3.1. So I don't actually fully understand the problem, but it sounds
like a firmware bug to me. Suffice to say, with Windows having enabled TRIM by
default for all SSDs, if a drive is corrupting its data, this ought to be
quickly remedied with a firmware update I'd think.
>
>> Until the industry gets its act together on TRIM, I think we're probably
>> better off executing fstrim once a week with a cron job at a time the
>> computer is likely to be idle.
>
> And what is TRIM and fstrim?
Ultimately you don't need to worry about it because TRIM isn't used by default
on Fedora. This is enabled with the discard mount option. As far as I know,
only Ubuntu has said they will use discard by default in the near future.
You can read more on TRIM on wikipedia and elsewhere if you're interested. The
gist is it's a way to inform the SSD of pages that are no longer in use by the
file system, i.e. deleted files, rather than files that have been overwritten.
This optimization is desirable, but only if it works correctly. And right now
it's not universally working correctly.
fstrim is a user space program to manually issue TRIM, so it can be done when
the drive is idle, and therefore negative side effects of the discard mount
option aren't readily noticed - those primarily being short term performance
problems that seem like a system hang for a few seconds (or in some extreme
cases up to a minute or two).
Where you're likely to experience a particular need for fstrim or discard is if
you have a fairly full SSD, with more file delete and create workload rather
than file overwrite workload. So if your SSD has a lot of unused space you're
unlikely to notice SSD slow down as a result of the SSD not having many pages
erased and ready for writes.
It's sort of a complicated issue.
Chris Murphy
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
