From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Subject: Re: discard and barriers Date: Tue, 17 Aug 2010 11:59:20 +0100 Message-ID: <1282042760.2507.11.camel@localhost> References: <20100814115625.GA15902@lst.de> <20100814141451.GB14960@thunk.org> <20100814145210.GA23126@lst.de> <1281951711.2500.25.camel@localhost> <20100816112615.GA10273@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: "Ted Ts'o" , hughd@google.com, hirofumi@mail.parknet.co.jp, chris.mason@oracle.com, linux-fsdevel@vger.kernel.org, jaxboe@fusionio.com, martin.petersen@oracle.com To: Christoph Hellwig Return-path: Received: from mx1.redhat.com ([209.132.183.28]:34560 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750945Ab0HQK7I (ORCPT ); Tue, 17 Aug 2010 06:59:08 -0400 In-Reply-To: <20100816112615.GA10273@lst.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi, On Mon, 2010-08-16 at 13:26 +0200, Christoph Hellwig wrote: > On Mon, Aug 16, 2010 at 10:41:51AM +0100, Steven Whitehouse wrote: > > GFS2 has a similar concept, which compares two bit maps to generate the > > extent list to generate the discards. This is done after each resource > > group has been committed to the journal, and just before the resource > > group bitmap is updated with the newly freed blocks (and marked dirty). > > > > Any remote node wanting to use that new space will cause a further > > journal flush when it requests the resource group lock (as well as in > > place write back of that resource group, of course). > > > > If the local node wants to reuse the recently freed space, then that can > > happen as soon as the log commit has finished, so in this case the > > barrier and the waiting are required. > > I don't think you need the barrier for that. The wait means the > discard has finished, and from that point writes to the blocks discarded > are safe. There's no need to flush the volatile write cache after > a discard either. The big question is if you need the drain before > the discard. Given that you did a log commit before I suspect not > as the log commit waits on all I/Os related to this commit. > Yes, that sounds reasonable in that case. I didn't know there were reordering guarantees with discards vs normal I/O so, in that case there is no need for the barrier. I don't think anything more is required in this case, so we should be good to go, Steve.