Mark
On Wed, 1 Dec 1999, Neil Brown wrote:
> 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/