On 20/05/13 15:12, David Boreham wrote:
> On 5/19/2013 7:19 PM, Toby Corkindale wrote:
>> On 13/05/13 11:23, David Boreham wrote:
>>> btw we deploy on CentOS6. The only things we change from the default
>>> are:
>>>
>>> 1. add "relatime,discard" options to the mount (check whether the most
>>> recent CentOS6 does this itself -- it didn't back when we first deployed
>>> on 6.0).
>>
>>
>> While it is important to let the SSD know about space that can be
>> reclaimed, I gather the operation does not perform well.
>> I *think* current advice is to leave 'discard' off the mount options,
>> and instead run a nightly cron job to call 'fstrim' on the mount point
>> instead. (In really high write situations, you'd be looking at calling
>> that every hour instead I suppose)
>>
>> I have to admit to have just gone with the advice, rather than
>> benchmarking it thoroughly.
>
>
> The guy who blogged about this a couple of years ago was using a
> Sandforce controller drive.
> I'm not sure there is a similar issue with other drives. Certainly we've
> never noticed a problematic delay in file deletes.
> That said, our applications don't delete files too often (log file
> purging is probably the only place it happens regularly).
>
> Personally, in the absence of a clear and present issue, I'd prefer to
> go the "kernel guys and drive firmware guys will take care of this"
> route, and just enable discard on the mount.
This guy posted about a number of SSD drives, and enabling discard
affected most of them quite negatively:
http://people.redhat.com/lczerner/discard/ext4_discard.html
http://people.redhat.com/lczerner/discard/files/Performance_evaluation_of_Linux_DIscard_support_Dev_Con2011_Brno.pdf
That is from 2011 though, so you're right that things may have improved
by now.. Has anyone seen benchmarks supporting that though?
Toby
