From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: barriers vs. reads Date: Wed, 23 Jun 2004 18:52:22 +0200 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040623165221.GO1120@suse.de> References: <20040622205309.GC3200@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jamie Lokier , linux-fsdevel@vger.kernel.org, Werner Almesberger Return-path: Received: from ns.virtualhost.dk ([195.184.98.160]:64705 "EHLO virtualhost.dk") by vger.kernel.org with ESMTP id S266565AbUFWQwY (ORCPT ); Wed, 23 Jun 2004 12:52:24 -0400 To: Bryan Henderson Content-Disposition: inline In-Reply-To: List-Id: linux-fsdevel.vger.kernel.org On Wed, Jun 23 2004, Bryan Henderson wrote: > >> Are you saying that if Sector A contains "foo", and I do a > >> __make_request(Write, Sector A, "bar") and then a __make_request(Read, > >> Sector A), the read might read "foo"? Assuming no barriers. > > > >Well no, even for direct io we maintain ordering if you hit an alias. > >... > >If you have overlapping requests, then you could get into serious > >trouble. You should not do that. > > What is an alias, and how is it different from an overlap? It's just an internal problem - when you add a request to the rbtree of the io scheduler, and an existing request with that key (start location) already exists. > Also: The question is about the block layer, but you answer in terms > of direct I/O. Does __make_request() know what direct I/O is? I > thought it just did I/O for I/O's sake. The block layer doesn't know and it doesn't care. I answer in terms of direct IO since that's the only way you'll get a request issued for the same sector. As mentioned below, the page cache prevents that from happening. > >The page cache will make sure don't see "foo", since you'll wait for the > >page to unlocked at the end of io. > > If it's a page cache page, the point is moot because the elevator would > never see the sequence of requests in question. But my question is about Precisely. > the general case, with no assumptions about who is calling > __make_request() and why. As stated earlier in this thread, the io scheduler makes no real attempt to cope with this scenario. Users of direct io are expected to syncronize themselves. It would be pretty silly not to do this, if only for performance reasons. The fact that the io scheduler catches "aliases" is not a feature and not something that is really useful in this respect, since it's only a slight subset of the general problem of overlapping ios. -- Jens Axboe