From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: discard and barriers Date: Sat, 14 Aug 2010 19:22:20 +0200 Message-ID: <20100814172220.GA29741@lst.de> References: <20100814115625.GA15902@lst.de> <20100814141451.GB14960@thunk.org> <20100814145210.GA23126@lst.de> <20100814154636.GP3315@think> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Chris Mason , Christoph Hellwig , "Ted Ts'o" , hughd@google.com, hirofumi@mail.parknet.co.jp, swhiteho@redhat.com, linux-fsdevel@vge Return-path: Received: from verein.lst.de ([213.95.11.210]:55375 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752929Ab0HNRWt (ORCPT ); Sat, 14 Aug 2010 13:22:49 -0400 Content-Disposition: inline In-Reply-To: <20100814154636.GP3315@think> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sat, Aug 14, 2010 at 11:46:36AM -0400, Chris Mason wrote: > Another way to say this is we have to be 100% sure that if we write > something after a discard, that storage will do that write after it does > the discard. Once we don't have barriers anymore the only way to do that is to wait for the discard to finish before submitting that I/O. > I care a lot about the write after the discards though. If the discards > themselves become async, that's ok too as long as we have some way to do > end_io processing on them. You can just submit the discard bio yourself. That's what I do in the current XFS code. It's a bit awkward that you have to do all the size checking yourself currently, but we could make that a common helper, I just don't want to do that now as it would create all kinds of dependencies for merging the trees in the .37 window.