From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: discard and barriers Date: Sun, 15 Aug 2010 23:30:13 +0200 Message-ID: <20100815213013.GA17594@lst.de> References: <20100814115625.GA15902@lst.de> <20100814141451.GB14960@thunk.org> <20100814145210.GA23126@lst.de> <20100815173906.GA20124@thunk.org> <20100815190230.GA11416@lst.de> <20100815212534.GE20124@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , hughd@google.com, hirofumi@mail.parknet.co.jp, chris.mason@oracle.com, swhiteho@redhat.com, linux-fsdevel@vger.kernel.org, jaxboe@fusionio.com, martin.petersen@oracle.com To: "Ted Ts'o" Return-path: Received: from verein.lst.de ([213.95.11.210]:56690 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750802Ab0HOVal (ORCPT ); Sun, 15 Aug 2010 17:30:41 -0400 Content-Disposition: inline In-Reply-To: <20100815212534.GE20124@thunk.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Aug 15, 2010 at 05:25:34PM -0400, Ted Ts'o wrote: > OK, now I understand why I'm confused. I thought the proposal was to > change sb_issue_discard() to make it be asynchronous? Really, what > we're talking about here is eliminating the explicit > barrier/SYNCHRONIZE CACHE from the discard, correct? The > sb_issue_discard() call will still remain synchronous. Yes, at least for now. I don't think keeping it that way over the long run is a good idea, but for now getting rid of the barrier is all that *needs* to be done. The rest is optimizations that can be done later.