On Tuesday 15 May 2001 12:44, Alexander Viro wrote:
> On Tue, 15 May 2001, Daniel Phillips wrote:
> > That's because you left out his invalidate:
> >
> > * create an instance in pagecache
> > * start reading into buffer cache (doesn't invalidate, right?)
> > * start writing using pagecache (invalidate buffer copy)
>
> Bzzert. You have a race here. Let's make it explicit:
>
> start writing
> put write request in queue
> block on that
> start reading into buffer cache
> put read request into queue
> read from media
> write to media
>
> And no, we can't invalidate from IO completion hook.
>
> > * lose the page
> > * try to read it (via pagecache)
> >
> > Everthing ok.
>
> Nope.
The problem is that we have two IO operations on the same physical
block in the queue at the same time, and we don't know it. Maybe we
should know it.
For your specific example we are ok if we do:
* create an instance in pagecache
* start reading into buffer cache (doesn't invalidate, right?)
* start writing using pagecache (invalidate buffer copy)
* lose the page (invalidate buffer copy)
* try to read it (via pagecache)
We are also ok if we follow my suggested optimization and move the page
to the buffer cache instead of just losing it.
We are not ok if we do:
* try to read it (via buffercache)
because its copy is out of date, but this can be fixed by enforcing
coherency in the request queue.
1) Why should the request queue not be coherent?
2) Can we stop talking about buffer cache here and start talking about
blocks mapped into a separate address space in the page cache? From
Linus's previous comments in this thread we are going to have that
anyway, and your race also applies there.
I'd like to call that separate address space a 'block cache'.
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
