Messages in this thread |  | | Date | Fri, 18 Oct 1996 13:16:17 +0100 (MET) | From | Ingo Molnar <> | Subject | Re: "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
|  |