jf@ap.co.umist.ac.uk (John Forrest) (02/08/91)
This is a similar vain to the current requests regarding Gatorbox NFS v alternatives. Can someone fill me in on a comparison on using NFS from the Mac (be it via Gatorboxes or direct from the Macs) and using CAP software on Unix boxes. I assume that if you start using NFS the file type/creator information of Mac files dissapears - or have I missed something? How do external (Unix created) files appear in both these environments. John Forrest Dept of Computation UMIST PS. Thanks to all those people who sent me info about MacX loadings.
wiechman@athos.rutgers.edu (NightMeower) (02/10/91)
When using GatorShare, files do not loose their attributes. All of
the bits and stuff are saved for you. I know this for a fact because
I use it regularly. For all intensive purposes, the GatorShare volume
appears to be like any other disk or floppy. Setup is also fairly
simple, no need to have to be a guru to use it. I am also fairly
certain that Aufs does not loose this information either.
I am also impressed with the tech support that we have received from
the Cayman people.
Kevin
--
===========================================================================
Kevin S. Wiechmann arpa: wiechman@cs.rutgers.edu
This is only a test... for the next sixty seconds...geo@moldev.com (George Pontis) (02/11/91)
There seems to be a detail in the installation of Appleshare services that's getting away from a lot of people, and leads to the problems mentioned here regarding files losing their attributes. The secret is to have a a pair of world-writeable directories named .finderinfo and .resource in the directory ABOVE the directory that gets mounted by the Mac. -- George Pontis ( geo@moldev.com )
jqj@duff.uoregon.edu (JQ Johnson) (02/12/91)
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
kdb@macaw.intercon.com (Kurt Baumann) (02/13/91)
In article <Feb.9.13.00.33.1991.9626@athos.rutgers.edu>, wiechman@athos.rutgers.edu (NightMeower) writes: > Path: intercon!uupsi!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!sun-barr!newstop!sundc!seismo!dimacs.rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!wiechman > From: wiechman@athos.rutgers.edu (NightMeower) > Newsgroups: comp.protocols.appletalk > Subject: Re: NFS access v CAP Software > Message-ID: <Feb.9.13.00.33.1991.9626@athos.rutgers.edu> > Date: 9 Feb 91 18:00:35 GMT > References: <1991Feb7.222518.18726@cns.umist.ac.uk> > Organization: Rutgers Univ., New Brunswick, N.J. > Lines: 16 > > When using GatorShare, files do not loose their attributes. All of > the bits and stuff are saved for you. I know this for a fact because > I use it regularly. For all intensive purposes, the GatorShare volume > appears to be like any other disk or floppy. Setup is also fairly > simple, no need to have to be a guru to use it. I am also fairly > certain that Aufs does not loose this information either. > You don't loose attributes when you use any of the other NFS products either, doing so would be a big loose, if you know what I mean. :-) > I am also impressed with the tech support that we have received from > the Cayman people. > The Cayman people are excellent with their tech support. We have always gotten good responses from them. Kurt Baumann InterCon Systems Corporation 703.709.9890 Creators of fine TCP/IP products 703.709.9896 FAX for the Macintosh.