Re: Force client page cache invalidation?

[ralph gonzalez <rgonzale@ibl.bm>]

[snip]
 >> Linux 2.4.22-10mdk (nfs utils 1.0.5) seems to be unwilling to reload the
 >> file cache *when another application already has the file mmapped*.
 >
 > Which is quite sane semantics for mmap().

Agreed...

[snip]
 >>*Question*: Instead, is there a way to force the client to reload the
 >
 > file cache (exclusively for this file)? (So when we subsequently
 > close/open the file in each application asynchronously, they see the
 > correct pages.) Maybe there's a simple option or utility I'm missing?
 >
 > Linux does not support this sort of kludge and is unlikely to do so for
 > the near future. The VM simply cannot support it.
 >
 > In any case, the fact is that strict POSIX mmap() semantics assume
 > exclusive access to the file on the server while it is mapped on a given
 > client. If you're not providing that, then you are going to be prone to
 > some nasty races whether or not the cache invalidation works like Solaris
 > does.

I wasn't aware of the POSIX semantics. It's a shame, since we've been
using this approach -- multiple readers and single writer -- on Solaris
for 8 years with excellent stability and performance. When we switched to
Linux we found this unexpected and unfriendly behavior:

   If NFS client has the file mmapped while it is edited on the server,
   and the client then opens a second application which mmaps the file
   (without closing the first application), then no matter what you do
   -- close both clients, etc -- the file cache never releases the old
   pages!

-- 
Ralph Gonzalez
rgonzale@ibl.bm



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs