lkml.org 
[lkml]   [1996]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Alternate solutions (Was: Re: NFS still has caching problem) (fwd)
Date
On Wed, 24 Jul 1996 06:55:40 -0400 (EDT), Jim Nance <Jim_Nance@avanticorp.com> wrote:
> Forwarded message:
>
> > We surely need NFS for compatibility with the rest of the world, but it
> > doesn't mean we should use it for ever. If the new file system will prove
> > its usefullness, it will be surely implemented on other architectures as lots
> > of people are not happy with Sun NFS and are waiting for some better standard.
>
> Perhaps we ought to do NFS V3 before we write out own.

Good idea.

But just what is the problem with NFS V2 under Linux? Reads are fine and the
write performance is getting better all the time - so I guess that leaves
lockd and statd - specs for which aren't freely available.

So how about we write our own lockd and statd - based on what we think it
should act like? I get the impression those two are "userland" processes -
so once the thing is made - there should be nothing to stop it also being
ported to other OSes. I hardly know squat about the internals of lockd, but
doesn't it just involve client/server lockd processes talking to each other,
telling them when a local file is locked/unlocked so that the other system
can do the same? We could call it llockd and make it a new RPC program so
that other Unices could run it and still use their own lockd.


--
Cheers,
+++++++++++++++++++++++++++++++++++++++++++++++
Jason Haar, Unix/Internet Manager
OiT, Oxford. Phone: +44 1865 785051



\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.034 / U:0.292 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site