Messages in this thread | | | Date | Tue, 15 Apr 2003 05:56:37 +0100 | From | Jamie Lokier <> | Subject | Re: Memory mapped files question |
| |
H. Peter Anvin wrote: > > Hi, everyone. Thanks for all your responses. Our confusion is > > that in Unix environments, when we modify memory in memory-mapped > > files the underlying system flusher manages to flush the files for > > us before the files are munmap'ed or msysnc'ed. > > Bullshit. It might work on one particular Unix implementation, but > the definition of Unix, the Single Unix Standard, does explicitly > *not* require this behavior.
I presume that if you do write(), the Single Unix Standard allows the data to remain dirty in RAM for an arbitrary duration too.
If I write() a file I expect it to be automatically written to disk within a few minutes at most, where that is plausible.
Frank van Maarseveen wrote: > Shared mmaped files are _never_ flushed, at least in 2.4.x. So, > without an explicit msync() a process (innd comes to mind) may loose > years of updates upon a system crash or power outage.
It's a quality of implementation issue if data can remain dirty in RAM forever without ever being flushed.
Can this really happen with normal open/mmap/munmap/close usage, or does it only occur with long-lived processes like innd which mmap a file, dirty the pages but never munmap them?
If the former case does happen, I'd say we're failing on quality of implementation. If it's only the latter case, though, fair enough: the application writer will have to use msync().
-- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |