SSD Partitioning OP/Trim recommendations

[Chris Murphy]

On Dec 18, 2013, at 11:50 AM, Robert Moskowitz <rgm at htt-consult.com> wrote:

> 
> On 12/18/2013 01:32 PM, Chris Murphy wrote:
>> 
>> On Dec 18, 2013, at 6:03 AM, Robert Moskowitz <rgm at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20131218/69df4a4b/attachment.html>