[lkml]   [2003]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:34    [W:0.019 / U:6.428 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site