Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!umd5!steveg
From: steveg@umd5.umd.edu (Steve Green)
Newsgroups: comp.unix.aux
Subject: Re: A/UX 2.0 and NFS
Message-ID: <7049@umd5.umd.edu>
Date: 7 Aug 90 01:07:10 GMT
References: <12171@hydra.gatech.EDU> <2042@cod.NOSC.MIL>
Reply-To: steveg@umd5.umd.edu (Steve Green)
Organization: University of Maryland, College Park
Lines: 28

In article <2042@cod.NOSC.MIL> zimmer@cod.NOSC.MIL (Thomas L. Zimmerman) writes:
>From article <12171@hydra.gatech.EDU>, by wj4@prism.gatech.EDU (JOYE,WILLIAM A):
>> 
>> Just a note about some info I found out from AUX support. Seems A/UX 2.0 
>> uses NFS version 2.0. SunOS 4.0.3 uses NFS 3.0. There have been several
>
>Bill,
>
>Can you amplify on the reported incompatabilities?  I am running A/UX 2.0
>on MacII with most of my file system mounted from a Sun running 4.0.3 and
>have not had any problems (unless you count the network storm I caused by
>setting the wrong broadcast address on the mac :-) ).  
>

On a related but unrelated subject... I had some problems with NFS.  The
symptom was that ld was creating bad file and known good source code
did not work.  After some time, this is the responce I got from Apple.

      You asked about the problem where the loader can write a block of
      zeroes to your output file when you are linking across NFS.  
      Apparently, the problem is caused by race conditions between 
      the multiple processes you get to do the file I/O.  We are currently
      looking at a fix for this.  A short term solution would be to run
      without biod daemons, which are the asynchronous block I/O daemons.
      Without these, you will get serial I/O, thus eliminating the race
      condition.

And sure enough, that took care of my problems.