From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH] block: fix DISCARD_BARRIER requests Date: Thu, 17 Jun 2010 18:54:53 +0200 Message-ID: <20100617165453.GA15824@lst.de> 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 verein.lst.de ([213.95.11.210]:38169 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933068Ab0FQQy6 (ORCPT ); Thu, 17 Jun 2010 12:54:58 -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: > Thanks, applied. There was a recent problem report on btrfs using > discard, could possibly explain it if Chris assumed it was a full > barrier. We actually have a much bigger issue with the DISCARD_BARRIER type. If the discard request needs to get split into multiple smaller ones we don't keep the queue drained atomically around them, so requests could sneak inbetween them. Depending on how the realtime discard is implemented that could cause issues. In my XFS prototype for it I only deleted the extents from the tracking betree after the discard request has returned, but other filesystems rely on full barrier semantics of DISCARD_BARRIER this could cause real problems.