Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)

From: Jari Sundell
Date: Wed Dec 27 2006 - 07:36:01 EST


On 12/27/06, Linus Torvalds <torvalds@xxxxxxxx> 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

Attachment: extend_mapping.diff
Description: Binary data