Messages in this thread | | | Date | Mon, 14 May 2001 22:45:37 +0200 | Subject | RE: [NFS] [PATCH] New patch to flush out dirty mmap()ed NFS pages in 2.4.4 | From | Trond Myklebust <> |
| |
>>>>> " " == Chuck Lever <cel@netapp.com> writes:
> the default behavior is that close() waits for all write-backs > to be committed to the server's disk. you might add support > for the "nocto" mount option so that waiting is skipped for > shared mmap'd files, but then what happens to data that is > pinned on the client because a write-back failed after close() > returns to the application?
It gets written back slowly (by flushd) or the user can speed things up using msync(). The latter will wait on completion. In addition, I fixed up sys_sync() so that it (and also bdflush, & friends) now also synchronizes to the server...
> what's the application domain Linus is trying to optimize?
AFAIK the most common use of (writeable) mmap() is for caching and possibly for local IPC.
As I understood it, Linus' position is that we have msync() as a documented generic synchronization point. Since, we were unable to find any examples of programs that rely on stricter rules for mmap (barring those which actually use locking), he suggested that our policy should be that which impacts the least on performance.
Cheers, Trond - 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/
| |