RE: [NFS] [PATCH] New patch to flush out dirty mmap()ed NFS pages in 2.4.4

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == 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