On Tue, 21 May 2013 11:40:55 +1000, Toby Corkindale wrote:
>>> 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)
This is still a good idea - see below.
>> The guy who blogged about this a couple of years ago was using a
>> Sandforce controller drive.
Btw that doesn't mean anything (neither in terms of performance nor
stability), since "the controller" also needs to be paired with an - often
vendor-dependent - firmware, which is much more relevant. Since LSI
acquired Sandforce this situation has gotten much better (unified
upstream).
>> I'm not sure there is a similar issue with other drives. Certainly we've
There is (now), because..
>> 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.
Nope, wrong, because.. (..getting there :)
> That is from 2011 though, so you're right that things may have improved by
> now.. Has anyone seen benchmarks supporting that though?
Unfortunately since 3.8 discards are issued as synchronous commands,
effectively disabling any scheduling/merging etc. The result can be seen
easily:
- mount drive without discard using kernel >= 3.8
- unpack kernel source
- time delete of entire tree
- remount with discard
- unpack kernel tree
- start delete of tree
- ...
- check it hasn't crashed
- ...
- go plant a tree or make babies while waiting for it to finish
Online discard has gotten so slow that it's now a good idea to turn off
for anything but light write workloads. Metadata-heavy writes are
obviously the worst case.
I experienced this on Samsung, Intel & a Sandforce-based drives, so "the
controller" is no longer the primary reason for the performance impact.
Extremely enterprisey drives *might* behave slightly better, but I doubt
it; flash erase cycles are what they are.
-h
