jaa@cluster.cs.su.oz.au (James Ashton) (05/03/91)
There seem to be a large number of bugs with this programme. We have found the following problems using fcntl to gain advisory exclusive locks across multiple hosts. Occasionally, locks are granted to many local processes simultaneously for a file while locking for the same file operates correctly on remote hosts. When rpc.lockd is not running (it occasionally dies), processes which request locks block permanently and cannot be killed. Sometimes rpc.lockd consumes vast numbers of mbufs which eventually brings the machine down. Where file systems are remotely mounted with different names, the files are not considered to be the same. E.g. we have two machines basser and orthanc. /usr/tmp/tmp on orthanc is nfs mounted as /n/orthanc/usr/tmp/tmp on basser but it is possible to simultaneously gain exclusive locks on this file from each machine. Locks seem not to be reliably released when a process is killed while holding a lock. We have 4.51 installed and are close to changing over to 4.52 but rpc.lockd is apparently not modified in the new release. Has anyone fixed up these problems which seem to make file locking fairly difficult? Are others having these problems or could it be something incorrectly set up with our configuration? Any information would be appreciated. James Ashton.
trevc@tecate.mips.com (Trevor Cotton) (05/04/91)
In article <2383@cluster.cs.su.oz.au>, jaa@cluster.cs.su.oz.au (James Ashton) writes: |> There seem to be a large number of bugs with this programme. We have |> found the following problems using fcntl to gain advisory exclusive |> locks across multiple hosts. |> |> Occasionally, locks are granted to many local processes simultaneously |> for a file while locking for the same file operates correctly on remote |> hosts. |> |> When rpc.lockd is not running (it occasionally dies), processes which |> request locks block permanently and cannot be killed. |> |> Sometimes rpc.lockd consumes vast numbers of mbufs which eventually |> brings the machine down. |> |> Where file systems are remotely mounted with different names, the files |> are not considered to be the same. E.g. we have two machines basser and |> orthanc. /usr/tmp/tmp on orthanc is nfs mounted as /n/orthanc/usr/tmp/tmp |> on basser but it is possible to simultaneously gain exclusive locks |> on this file from each machine. |> |> Locks seem not to be reliably released when a process is killed while |> holding a lock. |> |> We have 4.51 installed and are close to changing over to 4.52 but |> rpc.lockd is apparently not modified in the new release. Has anyone |> fixed up these problems which seem to make file locking fairly |> difficult? Are others having these problems or could it be something |> incorrectly set up with our configuration? Any information would |> be appreciated. |> |> James Ashton. Our engineering group has spent a large amount of time fixing numerous problems in the Sun rpc.lockd code. The fruits of their labor are available in the form of an updated rpc.lockd for RISC/os 4.52. If you have software maintenance, you can contact the MIPS Customer Response Center on 1-800-443-MIPS to request a copy. -- --trevc-- Trevor Cotton, Sustaining Engineering, MIPS Computer Systems Inc. MS 6-05, 930 DeGuigne Drive, Sunnyvale, CA 94088-3650 Tel: +1 408 524 7286 Fax: +1 408 524 7521 Email: {wyse,ames,decwrl,pyramid}!mips!trevc trevc@mips.com
kdenning@genesis.Naitc.Com (Karl Denninger) (05/04/91)
In article <3019@spim.mips.COM> trevc@mips.com writes: >In article <2383@cluster.cs.su.oz.au>, jaa@cluster.cs.su.oz.au (James Ashton) writes: >|> There seem to be a large number of bugs with this programme. We have >|> found the following problems using fcntl to gain advisory exclusive >|> locks across multiple hosts. >|> > >Our engineering group has spent a large amount of time fixing numerous >problems in the Sun rpc.lockd code. The fruits of their labor are available >in the form of an updated rpc.lockd for RISC/os 4.52. > >If you have software maintenance, you can contact the MIPS Customer Response >Center on 1-800-443-MIPS to request a copy. I have the MIPS "fixed" rpc.lockd. They have a HUGE memory leak in them which makes the process grow until it consumes all available physical memory. Last time I killed it, the process had more than 4,000 pages checked out! Try again please. -- Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 kdenning@nis.naitc.com "The most dangerous command on any computer is the carriage return." Disclaimer: The opinions here are solely mine and may or may not reflect those of the company.
lamy@sobeco.com (j.lamy) (05/06/91)
trevc@mips.com writes: >Our engineering group has spent a large amount of time fixing numerous >problems in the Sun rpc.lockd code. The fruits of their labor are available >in the form of an updated rpc.lockd for RISC/os 4.52. kdenning@genesis.Naitc.Com (Karl Denninger) writes: >I have the MIPS "fixed" rpc.lockd. > >They have a HUGE memory leak in them which makes the process grow until it >consumes all available physical memory. >Last time I killed it, the process had more than 4,000 pages checked out! > >Try again please. Neither the RISC/os 4.51 rpc.lockd or the 4.52 rpc.lockd will interoperate properly with SCO Unix, Dell SVR4 or UHC SVR4 NFS implementations. The first one is a killer, as it interferes with using things like UNIX versions of WordPerfect and Lotus (which don't ship on RISC/os) with files mounted across NFS. WordPerfect release notes even devote 2 pages on the topic (the problem is not specific to RISC/os, as Suns used to exhibit much the same behaviour among themselves). In fact, some PC-NFS implementors apparently have such a high opinion of rpc.lockd that they ship a combination authentication/locking daemon. Beame and Whitesides apparently does this; Intercon's technical support (they do an NFS for Macs) recommended configuring their product to use the B&W bwnfsd for servers to work around rpc.lockd brain damage. NFS: Not a File System? Heaven help us, but maybe it'll end up meaning Novell For Sure if nothing is done about it... PC and Mac AFS anyone? Jean-Francois Lamy lamy@sobeco.com, lamy@sobeco.ca, uunet!sobeco!lamy Research and Development, Sobeco Technical Services, Montreal, Canada H2Z 1Y7