Messages in this thread |  | | Subject | Re: "raw" block devices? | Date | Fri, 18 Oct 1996 11:49:47 +0200 | From | Alain KNAFF <> |
| |
>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
|  |