Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!ogicse!milton!ns.uoregon.edu!duff.uoregon.edu!jqj From: jqj@duff.uoregon.edu (JQ Johnson) Newsgroups: comp.protocols.appletalk Subject: Re: NFS access v CAP Software Keywords: CAP, aufs, NFS, file locking Message-ID: <1991Feb11.224240.5383@ns.uoregon.edu> Date: 11 Feb 91 22:42:40 GMT References: <1991Feb7.222518.18726@cns.umist.ac.uk> Sender: news@ns.uoregon.edu Reply-To: jqj@duff.uoregon.edu (JQ Johnson) Organization: University of Oregon Network Services Lines: 39 I observed recently what appeared to be a rather severe problem with CAP performance. The configuration was a CAP server running on SunOS4.1.1 with enet (packet filter) support. This Sun was an NFS client of a file server that held the actual files i.e. the CAP server was acting as an AppleShare to NFS translator. Performance in this configuration was dismal, with download file transfer rates in the 100 bytes/sec range even to an Ethertalk Mac. Perhaps worse, it occasionally tickled some bug in rpc.lockd that caused lockd to generate a stream of UDP packets which were answered only by an ICMP "port unreachable", even after the aufs process was killed. It turned out that CAP was doing an OSTestLock() for each packet to make sure that nobody else had locked the file. Each OSTestLock() translated into a lockf(fd,F_TEST,len) system call. lockf() in turn was implemented as a context switch and call to rpc.lockd, which in turn had to query the remote system (first, since we run with resolver routines in libc.so, a remote DNS lookup to turn the hostname in the mount point into an address, then an RPC call to the rpc.lockd on the NFS server). Rebuilding CAP without X_LOCKF in m4.setup increased file transfer performance by about 100x. Given that lockf() is very expensive for NFS-mounted files (in SunOS 4.1), how do other Aufs-to-NFS gateways (Pacer, Mt Xinu, Gatorbox, etc.) deal with the Appleshare file byte range locking and consistency requirements? Given that flock() [which is all I have left in CAP after I turn off lockf()] is only local to a particular machine, how can CAP guarantee to lock out writers on read-only files if the file is NFS-mounted and the writer is on a different system? Given that Sun's rpc.lockd is so fragile that it can get wedged by heavy use, why would anyone in his right mind trust it to guarantee file system consistency? -- JQ Johnson Director of Network Services Internet: jqj@oregon.uoregon.edu University of Oregon voice: (503) 346-4394 250E Computing Center BITNET: jqj@oregon Eugene, OR 97403-1212 fax: (503) 346-4397