Xref: utzoo comp.unix.questions:6230 comp.unix.wizards:7347 comp.arch:4057
Path: utzoo!mnetor!uunet!ncc!alberta!ubc-cs!chimay.cs.ubc.ca!sample
From: sample@chimay.cs.ubc.ca (Rick Sample)
Newsgroups: comp.unix.questions,comp.unix.wizards,comp.arch
Subject: Re: RFS vs. NFS
Message-ID: <1904@ubc-cs.UUCP>
Date: 25 Mar 88 01:01:09 GMT
References: <326@ivory.SanDiego.NCR.COM> <7765@apple.Apple.Com> <7533@brl-smoke.ARPA>
Sender: nobody@ubc-cs.UUCP
Reply-To: sample@chimay.cs.ubc.ca (Rick Sample)
Organization: UBC Department of Computer Science, Vancouver, B.C., Canada
Lines: 25

In article <7533@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>I don't like the lock/stat daemons but presumably they
>at least work;

My experience is that they work marginally, at best.  rpc.lockd is prone
to growing very large and then dropping a huge core file in /core.  Sun
claims that the 3.5 version is fixed.  The 3.5 lockd is better than the
3.2 lockd (it lasted about 12 hours before dying in our environment) but
is still not fixed.  I have a mostly fixed version of lockd, but I can't
distribute it, of course.

I think that the reason there hasn't been more complaint about lockd is
that very little use is made of it in a standard Sun environment.  We
run a locally developed X.400 message system as our standard mail system,
and it makes extensive use of the lock daemon.  When the lock daemon
dies (as it did very frequently before I modified it) the mail programs
hang and cannot be killed, causing much frustration to the unsuspecting
user.

There were numerous obvious bugs in the rpc.lockd code, many could be
found just by running lint.  I sent some of my fixes to Sun, but
I don't think they made it into the 3.5 release.  I don't have 3.5 source
code yet so I can't be sure.

Rick Sample, Facilities Manager, UBC Computer Science