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    [W:7.409 / U:0.096 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site