Just to clarify:
Security: Neutral (it's all in-kernel, on the userland side it just
simplifies code and is inherently security promoting as it just is a
symmetry aspect)
Will unifying it improve performance?: Yes, because programs with
dynamic file sizes will be able to MMAP up to some point and then
fread/fwrite beyond that one. (In contrast, having anticipatory 1TB
mmap:s for all mmap:ed files doesn't make sense.)
I think msync() is expensive, and unifying the buffer would remove
the need for msync():s all over the place!
Will it make the code simpler?: Userland code, yes, by indirectly
encouraging mmap use.
Details: SQLite has its mmap acceleration disabled on OpenBSD because
the mmmap-based access not is symmetric with the fread/fwrite which it
uses above the mmapped area and by default.
A "safe" approach to file access would be to read data using mmap() but
write data using fwrite() only. Mmap does have a read-only mode. This
does NOT work in OpenBSD currently though because of the absence of
unified caching.
(Sorry for not providing a diff for this.)
On 2015-11-10 13:36, Tinker wrote:
Really, unifying the buffer cache would make all sense in the world.
Also, *all* other major OS:es have done this already, so even just
doing it for the sake of symmetry would make sense.
I think I talked to someone who suggested that an attempt to unify had
been done before, and that the NFS filesystem drivers had been what
stopped it then, by some reason they were difficult. Perhaps that
could be worked around afterall?
On 2015-05-22 15:27, Tinker wrote:
Hi,
Will mmap and the read buffer cache be unified, anyone working with
it?
Some programs disable features on OBSD for this reason so would be
nice! (I admit though that a program combining mmap() and read() on
the same file sounds like a slightly quirky design choice to me.)
Thanks!
Tinker
