On 2017-04-05 18:05, Theo de Raadt wrote:
..
>> So presently higher-speed access is restricted to read()/write() -
>> noted.
>
> So what?
Yeah you're right - while some really nice code out there such as LMDB
depends on mmap, and mmap may be a bliss in how it abstracts away the
externality of a file from the programmer and from a program, then, of
course mmap is not a panacea or anything and I guess there are some
level of relevant security arguments against it.
I totally understand that rsd* is special and there's no point with
mmap:ing it, so normal access should be done on sd* . So then this
question transforms into the fairly recent what-about-higher-sd*
speeds
through multithreading and perhaps multiqueing misc@ thread with David
Gwyne on https://marc.info/?t=148660831800001&r=1&w=2 .
He talked about that the file IO subsystem is singlethreaded and he
had
made several but not all parts threadsafe, and so that it's a deep &
implementation question, and he didn't have the time to go into any
additional detail yet.
How strange. What David talked about has nothing to do with your
failure
to mmap a disk device.
I understand that the two have nothing at all to do with each other on
the system's internal and lower levels.
However to the question of how to tap into the highest performance level
of an NVME/SATA drive, they do - one way is via rsd*, which comes with
the constraints of aligned IO only (afaik) and no mmap (as you
clarified), and the other way is to wait for sd* to become fully
multithreaded someday or otherwise incur less overhead (exempted from
the big lock etc., or add multiqueueing support), the conversation with
David did not go so far as to bring light on the details.
