lkml.org 
[lkml]   [1996]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: "raw" block devices?
On Fri, 18 Oct 1996, Alain KNAFF wrote:

> We could solve this problem by introducing a new mmap flag: MAP_DB.
> Data mapped using this would _not_ spontaneously get written back to
> the mapped file. It would only get paged in from the file, and paged
> to swap, if memory is tight. An explicit msync() would be needed to
> sync it to disk (to be issued at commit). Or even better: an new
> mcoherent() syscall, to be issued at commit, which would _allow_ the
> kernel to copy the data to the file, without forcing it to do so
> immediately. The advantage of this latter approach would be a better
> commit latency.

i've just checked Postgres95 sources, and they use shared memory (called
SysCache) as a write-cache, thus they do double buffering. [their design
looks quite OK otherwise]

the problem with a MAP_DB flag is that it possibly penaltizes >all< memory
operations [and we need no RDBMS functionality in the kernel if we run a
simple web server]. It makes bdflush more complex. [we could in turn
rename it to dbflush =B-)]. And i'm not sure wether such functionality is
conceptually necessary in the kernel.

but vmareas with nondefault paging operators look like an intriquing
option :) [and they are already possible in the kernel? ... at least some
bits are there already :)]

[but show me the right way if i'm on the wrong track]

-- mingo



\
 
 \ /
  Last update: 2005-03-22 13:37    [from the cache]
©2003-2011 Jasper Spaans