From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: [PATCH] block: fix DISCARD_BARRIER requests Date: Thu, 17 Jun 2010 05:49:47 -0600 Message-ID: <20100617114947.GI9298@parisc-linux.org> References: <20100617075432.GA22407@lst.de> <4C19D86A.5030709@kernel.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , linux-fsdevel@vger.kernel.org, Chris Mason To: Jens Axboe Return-path: Received: from palinux.external.hp.com ([192.25.206.14]:47498 "EHLO mail.parisc-linux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759842Ab0FQLtt (ORCPT ); Thu, 17 Jun 2010 07:49:49 -0400 Content-Disposition: inline In-Reply-To: <4C19D86A.5030709@kernel.dk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."