[Info-vax] OpenVMS async I/O, fast vs. slow

[Craig A. Berry]

On 11/4/23 4:41 PM, Dan Cross wrote:
> In article <ui64is$3go9i$1 at dont-email.me>,
> Craig A. Berry <craigberry at nospam.mac.com> wrote:
>> For disk I/O, yes, it's
>> almost certain that using virtual memory primitives to synchronize
>> integral pages between disk and memory will be faster than any other I/O
>> method; that's why pretty much every database product on every platform
>> does it.
> 
> Everyone starts out thinking that, but most are wrong:
> https://db.cs.cmu.edu/mmap-cidr2022/

Interesting article.  I don't buy its conclusions as an indication of
what most databases do.  Its main point seems to be that mapped memory
makes transactions difficult because, "due to transparent paging, the OS
can flush a dirty page to secondary storage at any time, irrespective of
whether the writing transaction has committed."  Well, yeah, you have to
lock pages in memory, and apparently mlock() doesn't guarantee that it
does what is says on the tin. They also seem to be surprised by the fact
that paging to a remote storage system is slow.  Well, duh.  So there
are complexities and difficulties arising from using mapped memory.

But there are also complexities and difficulties with their recommended
alternative of "traditional buffer pools" and libaio or io_uring.  Stack
Overflow is full of articles about problems, including broken
implementations and security problems, with those APIs. I don't doubt
they can be useful if the complexities and difficulties are managed
correctly, but the same is true of mapped memory.

Also noteworthy is that in the long list of databases whose
implementations they considered, SQLite is the only major player they
mention. SQLite has an unusual storage model (data typing imposed at run
time, IIRC) and was never intended as a multi-user OLTP system, so its
I/O choices aren't much of a guide to what databases in general do.

If the authors of the article could show evidence that the research
teams at Oracle, Microsoft, and IBM have come to the same conclusions
they did and don't use mapped memory in their products anymore, that
would be interesting, but they make only an oblique reference to SQL
Server in a context that implies it does use mapped memory.

I suspect all of the major databases use any and every I/O mechanism
available in different situations, chosen by a variety of engine
choices, run-time heuristics, and configuration options. Mapped memory
may not be the only game in town besides file I/O like it once was, but
I'm just not buying that it's been entirely eclipsed.