From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: [PATCH] block: fix DISCARD_BARRIER requests Date: Thu, 17 Jun 2010 14:06:21 +0200 Message-ID: <4C1A0FBD.7070705@kernel.dk> References: <20100617075432.GA22407@lst.de> <4C19D86A.5030709@kernel.dk> <20100617114947.GI9298@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , linux-fsdevel@vger.kernel.org, Chris Mason To: Matthew Wilcox Return-path: Received: from 0122700014.0.fullrate.dk ([95.166.99.235]:39279 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751713Ab0FQMGV (ORCPT ); Thu, 17 Jun 2010 08:06:21 -0400 In-Reply-To: <20100617114947.GI9298@parisc-linux.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 2010-06-17 13:49, Matthew Wilcox wrote: > On Thu, Jun 17, 2010 at 10:10:18AM +0200, Jens Axboe wrote: >> On 2010-06-17 09:54, Christoph Hellwig wrote: >>> Filesystems assume that DISCARD_BARRIER are full barriers, so that they >>> don't have to track in-progress discard operation when submitting new I/O. >>> But currently we only treat them as elevator barriers, which don't >>> actually do the nessecary queue drains. >>> >>> Also remove the unlikely around both the DISCARD and BARRIER requests - >>> the happen far too often for a static mispredict. >> >> Thanks, applied. There was a recent problem report on btrfs using >> discard, could possibly explain it if Chris assumed it was a full >> barrier. > > If it was on real hardware (ie a SATA disc), it can't be this problem, > since TRIM isn't NCQ so there was already an implicit queue drain ahead > and behind the TRIM. I hear rumours of an NCQ TRIM coming 'RSN', but > haven't seen any details on it yet. Good point, it will drain the queue on SATA of course. The problem was reported on MMC, I doubt the do queuing at all (though I have not checked). -- Jens Axboe