Messages in this thread |  | | | Date | Wed, 27 Dec 2006 21:32:27 +0900 | | From | "Jari Sundell" <> | | Subject | Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3) | |
On 12/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
<snip>
> - 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 2.6.18.3 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] |  |