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

>one not-so obvious problem is that an RDBMS >has< to implement a
>write-cache for itself. Thus if the block device would be buffered too (in
>the kernel), then we had double buffering. [as it is buffered now]
>
>The kernel write cache spontanously writes data to the device, and this is
>not good for an RDBMS: it has to be sure that the cached data first
>touches the log, then only the actual database. If the kernel provided
>such a functionality, then RDBMSs could efficiently use the kernel
>buffering.
[...]
>If we could guarantee for a database that a page wont be written out only
>if the database server wants so ... then using mmap() for a database would
>be a much cleaner design [and probably would be faster too].

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.

Alain

\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.301 / U:1.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site