Re: barriers vs. reads

[Jamie Lokier <jamie@shareable.org>]

Werner Almesberger wrote:
> (For partially overlapping requests, it may actually be nice
> to be able to break them into multiple parts, and queue them
> separately. Particularly if they also come with distinct
> priorities.)

If there's a read which depends on a prior write, doesn't it make more
sense to just copy the data in memory for the parts which overlap?

If you do that, then you can service all high priority reads properly:
those that don't overlap can cross write barriers, and those that do
overlap can be copied in memory immediately.

There may be a case for forcing a direct read for programs which check
storage data integrity, although probably not even then is it useful.
(A program that wants to write some data and then read using direct
I/O will call write(), _wait_ until that returns after committing the
data, and then call read()).

Even if the current behaviour of requiring a device read after the
barrier must remain for ordinary direct I/O, it isn't required for
requests marked as "high-priority I/O".

-- Jamie