On 4/30/18 12:25 PM, Luis R. Rodriguez wrote: > On Mon, Apr 30, 2018 at 12:07:31PM -0600, Jens Axboe wrote: >> On 4/30/18 11:19 AM, Brian Foster wrote: >>> On Mon, Apr 30, 2018 at 09:32:52AM -0600, Jens Axboe wrote: >>>> XFS recently added support for async discards. While this can be >>>> a win for some workloads and devices, there are also cases where >>>> async bursty discard will severly harm the latencies of reads >>>> and writes. >>>> >>>> Add a 'discard_sync' mount flag to revert to using sync discard, >>>> issuing them one at the time and waiting for each one. This fixes >>>> a big performance regression we had moving to kernels that include >>>> the XFS async discard support. >>>> >>>> Signed-off-by: Jens Axboe <axboe@xxxxxxxxx> >>>> --- >>> >>> Hm, I figured the async discard stuff would have been a pretty clear win >>> all around, but then again I'm not terribly familiar with what happens >>> with discards beneath the fs. I do know that the previous behavior would >>> cause fs level latencies due to holding up log I/O completion while >>> discards completed one at a time. My understanding is that this lead to >>> online discard being pretty much universally "not recommended" in favor >>> of fstrim. >> >> It's not a secret that most devices suck at discard. > > How can we know if a device sucks at discard? This test usually works well - does it support discard? Then it probably sucks :-) But seriously, synthetic test case with reads/writes (the actual workload) and then mix in trims. If the performance suffers, then discards suck. Just consider this series - it was a 25% latency win. >> While the async >> discard is nifty and I bet works well for some cases, it can also cause >> a flood of discards on the device side which does not work well for >> other cases. > > Shouldn't async then be only enabled if the device used supports it well? > Or should a blacklist per device be more suitable? Which is more popular? You'd be left with nothing... My general recommendation is to not use discards at all, unless there's a proven case that it makes a write amplification difference for you - from at all, to "big enough that I'd suffer the latency consequences". -- Jens Axboe
