On February 4, 2002 05:02 pm, Steve Lord wrote:
> But async I/O itself needs synchronisation (being English in this email ;-)
> to be meaningful. If I issue a bunch of async I/O calls which overlap with
> each other then the outcome is really undefined in terms of what ends up
> on the disk. Scheduling of the actual I/O operations is really no different
> from them being synchronous calls from different user space threads.
>
> The only questions you can really ask is 'is read atomic with respect to
> write?' and 'are writes atomic with respect to each other?'. So when you
> perform a read it sees data from before or after writes, but never sees
> data from half way through a write. And for multiple write calls the output
> appears as if one write happened after the other, not intermingled
> with each other.
Why is it not ok to have the writes come out intermingled, if that's what the
user has asked for? (Implicitly, by not synchronizing the writes.)
> Irix actually takes the viewpoint that it only needs to make a best effort
> at synchronizing between direct I/O and other modes of I/O. Multiple
> direct writers are allowed into a file at once, and direct writers and
> buffered readers are also allowed to operate in parallel. At this point
> coherency is really up to the applications. I am not presenting this as
> a recommended model for linux, just reporting what it does.
I'm having a little trouble with this. Suppose an application does direct
IO on a file but, unbeknownst to it, some other program has done buffered
IO on the file, so that there are still dirty blocks in the page cache,
waiting to land by surprise on top of unbuffered data. A third program
may come along to do buffered IO on the file, and find stale blocks in
cache. Am I missing something here?
-- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:36 EST