From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [PATCH 0/7] Discard requests, v2 Date: Tue, 12 Aug 2008 19:10:55 +0100 Message-ID: <20080812181055.GB21341@shareable.org> References: <1218535205.2977.131.camel@pmac.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jens Axboe , Andrew Morton , Ric Wheeler , linux-fsdevel@vger.kernel.org, gilad@codefidence.com, matthew@wil.cx To: David Woodhouse Return-path: Received: from mail2.shareable.org ([80.68.89.115]:56343 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751852AbYHLSLG (ORCPT ); Tue, 12 Aug 2008 14:11:06 -0400 Content-Disposition: inline In-Reply-To: <1218535205.2977.131.camel@pmac.infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: David Woodhouse wrote: > I'd still quite like to make it work though -- file systems that care > can always use explicit barriers to ensure that the DISCARD requests are > handled before any subsequent reallocation and write to the same > sectors. Wouldn't an explicit barrier be (a) slow if it's a hard-barrier, and (b) as a soft-barrier, overly constrain scheduling, because the only ordering required is against a subsequent overlapping write? Explicit soft or hard barrier *before* DISCARD does need to be an option. Think of journalling: Step 1 = commit "deleted file" to journal, 2 = hard barrier, 3 = DISCARD file data. Barrier after does not seem to be required. -- Jamie