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/
This archive was generated by hypermail 2b29 : Tue Apr 15 2003 - 22:00:34 EST