[lkml]   [2006]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
    On 12/27/06, Linus Torvalds <> wrote:
    > - It never uses mprotect on the shared mappings, but it _does_ do:
    > "mincore()" - but the return values don't much matter (it's used
    > as a heuristic on which parts to hash, apparently)
    > I double- and triple-checked this one, because I
    > did make changes to "mincore()", but those didn't go
    > into the affected kernels anyway (ie they are not in
    > plain 2.6.19, nor in either)

    Correct, mincore is only used to check if it should delay the hash checking.

    > "madvise(MADV_WILLNEED)"
    > "msync(MS_ASYNC)" (or MS_SYNC if you use a command line flag)
    > "munmap()" of course
    > - it never seems to mix mmap() and write() - it does _only_ mmap.
    > - it seems to mmap/munmap the shared files in nice 64-page chunks, all
    > 64-page aligned in the file (ie it does NOT create one big mapping, it
    > has some kind of LRU of thse 64-page chunks). The only exception being
    > the last chunk, which it maps byte-accurate to the size.

    The length of the chunks is only page aligned on single file torrents,
    not so on multi-file torrents. I've attached a patch for rtorrent that
    will extend the length to the page boundary.

    > - I haven't checked whether it only ever has the same chunk mapped once
    > at a time.

    This should be the case, but two mapped chunks may share a page,
    sometimes with different r/w permissions.

    Jari Sundell
    [unhandled content-type:application/octet-stream]
     \ /
      Last update: 2006-12-27 13:37    [W:0.030 / U:17.340 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site