Re: barriers vs. reads

[Jens Axboe <axboe@suse.de>]

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