![]() | ||||||||||
Messages in this thread |
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/ | |||||||||
| Last update: 2005-03-22 12:34 [from the cache] ©2003-2008 | ||||||||||