From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:59348 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753608AbeD3SZ1 (ORCPT ); Mon, 30 Apr 2018 14:25:27 -0400 Date: Mon, 30 Apr 2018 18:25:25 +0000 From: "Luis R. Rodriguez" Subject: Re: [PATCH 2/2] xfs: add 'discard_sync' mount flag Message-ID: <20180430182525.GE27875@wotan.suse.de> References: <1525102372-8430-1-git-send-email-axboe@kernel.dk> <1525102372-8430-3-git-send-email-axboe@kernel.dk> <20180430171945.GB22176@bfoster.bfoster> <24df628d-c861-6f39-96a8-d759902d1fe3@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24df628d-c861-6f39-96a8-d759902d1fe3@kernel.dk> Sender: linux-xfs-owner@vger.kernel.org List-ID: List-Id: xfs To: Jens Axboe Cc: Brian Foster , linux-xfs@vger.kernel.org, linux-block@vger.kernel.org, hch@lst.de 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 > >> --- > > > > 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? > 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? Luis