Re: Help with non-standard mod to NFS Kernel daemon ...

Neil Brown (neilb@cse.unsw.edu.au)
Wed, 1 Dec 1999 09:59:40 +1100 (EST)

On Tuesday November 30, rodmur@maybe.org wrote:
> On Tue, Nov 30, 1999 at 04:55:52PM +0000, Mark O'Neill elucidated:
> > One of the nicest aspects of this system is a shared heap model which
> > permits processes to use mmap() (as opposed to sbrk() to create and share
> > data heaps. The problem is while this works very nicely if the
> > co-operating processes are on the same machine, it fails under NFS because
> > user processes on a client machine cannot tell the NFS kernel daemon on
> > that machine to flush all cached data back to the physical file on the
> > NFS server. How hard would it be to implement an additional system call
> > [say nfssync()] to perform this function? Typically this would not impinge
> > on NFS filesystem performance, as this (slow) operation would only need to
> > be called when a process has finished modifying a shared heap in order to
> > provide up-to-date data for other clients of that heap.
> >

Well... it should work. An 'fsync' on the client tells the client
kernel NFS implementation to send any cached write requests to the
server, and when the server receives the write request, it is required
by the protocol to store it to "stable storage" before repling to the
request. So after an fsync (or close) on the client, all the data
should be safe on disc on the server.

However, the linux kernel nfsd has an option (which is unfortunately
the default) to allow it to return before the data is safe. This
makes NFS server faster (20%?) but less safe.
If you export with the "sync" export option, it should write data
safely do disc before returning.

Does this address your problem? or did I miss something.

>
> I wonder if it would be better to use CODA, or similar shared FS, as
> opposed to NFS in this situation.

I don't think CODA would be an answer. From my understanding, it
doesn't allow shared write access to a file (the file gets copied,
whole, to which ever client has it open).

NeilBrown

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/