From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vladislav Bolkhovitin Subject: Re: [RFC] relaxed barrier semantics Date: Mon, 02 Aug 2010 14:38:18 +0400 Message-ID: <4C56A01A.1050107@vlnb.net> References: <20100729194904.GA17098@lst.de> <4C51DCF1.3010507@redhat.com> <25F5E16E-968D-4FEF-8187-70453985B19B@dilger.ca> <20100729230406.GI4506@thunk.org> <4C52CBFF.6090406@vlnb.net> <20100730130957.GA26894@lst.de> <4C52D2E0.5000609@vlnb.net> <20100730133410.GA27996@lst.de> <4C52D728.6070008@vlnb.net> <20100730142025.GA29341@lst.de> <20100731004756.GC3273@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ted Ts'o , Andreas Dilger , Ric Wheeler , Tejun Heo , Vivek Goyal , jaxboe@fusionio.com, James.Bottomley@suse.de, linux-fsdevel@vger.kernel.org, linux-scsi@vger.kernel.org, chris.mason@oracle.com, swhiteho@redhat.com, konishi.ryusuke@lab.ntt.co.jp To: Jan Kara , Christoph Hellwig Return-path: In-Reply-To: <20100731004756.GC3273@quack.suse.cz> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Jan Kara, on 07/31/2010 04:47 AM wrote: > On Fri 30-07-10 16:20:25, Christoph Hellwig wrote: >> On Fri, Jul 30, 2010 at 05:44:08PM +0400, Vladislav Bolkhovitin wrote: >>> Yes, but why not to make step further and allow to completely eliminate >>> the waiting/draining using ORDERED requests? Current advanced storage >>> hardware allows that. >> >> There is a few caes where we could do that - the fsync without metadata >> changes above would be the prime example. But there's a lot lower >> hanging fruit until we get to the point where it's worth trying. > Umm, I don't understand you. I think that fsync in particular is an > example where you have to wait and issue cache flush if the drive has > volatile write cache. Otherwise you cannot promise to the user data will be > really on disk in case of crash. So no ordering helps you. Isn't there the second wait for journal update? > And if you are speaking about a drive without volatile write caches, then > fsync without metadata changes is just trivial and you don't need any > ordering. A drive can reorder queued SIMPLE requests at any time doesn't matter if it has volatile write caches or not. So, if you expect in-order requests execution (with journal updates you do?), you need to enforce that order either by ORDERED requests or (local) queue draining. Vlad