HDTenEightyP/NetNews huggingface dataset:
From: costello@eplrx7.es.duPont.com (Tim Costello)
Newsgroups: comp.protocols.nfs
Subject: PCNFS & HP EtherTwist EISA CARD
Date: 6 Jan 93 21:29:02 GMT
Organization: DuPont Engineering Physics Laboratory


	Anybody tried to get PC-NFS 4.0a and an HP EtherTwist EISA card to
work together?  

	I recently tried to get this combination to work via the NDIS route,
with the latest NDIS drivers from HP.  This is in a Compaq Deskpro M EISA
machine.  Upon reaching the line of the CONFIG.SYS file that would load the
HP supplied NDIS driver, an error is seen that claims to be "unspecified"
and the HP driver fails to load.  I tried this with both the Protman.sys
supplied with PCNFS and the one supplied with the HP card and they both fail
to work properly.  With either a 3COM 3C505 or 3C507TP both work as
advertized using the NDIS route.  

	Just wondering if anyone has had any sucess/experience using this
card.....

-- 
Tim Costello
Du Pont Merck Pharmaceutical
costello@eplrx7.es.dupont.com
From: nol2321@dsacg4.dsac.dla.mil (Jim Dunn)
Newsgroups: comp.protocols.nfs
Subject: Re: duplicate files in NFS directory under heavy load?
Date: 12 Jan 93 15:40:54 GMT
Organization: Defense Logistics Agency Systems Automation Center, Columbus


>  This is noticable when doing a ``rename(2v)'' on a systems which
>does not give the appearance of atomaticity.  This is easy to demonstrate
>on an overloaded sun3 (:-))
>  With FFS, you say ``mv foo bar'' and for a brief period there is an entry for
>both foo and bar: the creation of bar is atomic, but the deletion of foo
>only appears atomic to the caller.  Other processes reading the directory
>can aften see both foo abd bar for a brief period over NFS.

I've got a BETTER one for yuh!  If you use PC-NFS with a Gould Unix box,
and turn the *sticky* bit on and then do a mv.exe or use Norton's Commander
or Directory Freedom to rename a directory... you'll get TWO entries with
the SAME I-Node FOREVER!!!

Yuck!
:-<
Jim
Newsgroups: comp.protocols.nfs
Subject: NFS between VMS and Unix - problem and questions
From: newsmgr@idiws1.idi.battelle.org
Date: 11 Jan 93 15:43:09 EST
Organization: IDI-Dublin

We have a VAX-VMS NFS server serving a variety of unix NFS clients including
Sun-os 4.1.3 and AIX V3.2. The server is running TGV's multinet - the product
I consider the best for that OS.

Every now and then, doing a "ls" on the client to a directory with 190 files
in it will return without reporting the entire directory contents. No errors
are returned by either the clients or the server. It just looks like the last
files in the directory never make it to the client. The directory itself is
not active - i.e. no changes/deletions /additions to entries.

We have sent a tcpdump output to the server vendor but I was more curious
about some more theoretical questions - 

1. The server is a busy (network and cpu-wise) old VAX 8700 with an ethernet
controller slower then most of today's workstations. Can network busy-ness
cause this to happen without causing an error or retry?

2. All of these nodes are on a ethernet - there are two ethernet bridges
the packets must travel thru to get from server to client. We do not
have any udp checksumming enabled. My thought was that on a ethernet, udp
checksumming was not necessary. Is this true? I thought the ethernet packet
checksumming would do the job but then again I am not an networking expert 
by any stretch of the imagination.

3. Is there any directory entry caching anywhere that could be a factor here?

4. Variants of the top problem include commands like echo * returning different
results like the "ls" command above and the "pwd" command sometimes returning
errors like "can't get current working directory" instead of the current
directory.


Any help will be appreicated.

Thanks
Don

Don Hamparian - VAX/VMS Systems Support
              - Unix Systems Support Apprentice
              - Networking Systems Support

Information Dimensions. A subsidiary of Battelle Memorial Institute.

Phone 614.761.7445
Internet: HAMPARIAN@IDICL1.IDI.BATTELLE.ORG
USMail:   5080 Tuttle Crossing Bl., Dublin OH 43017.

Disclaimer: My views in no way represent those of my employer.

Newsgroups: comp.protocols.nfs
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: NFS packet size
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 5 Jan 1993 19:27:53 GMT

In article <peterd.726170584@pjd.dev.cdx.mot.com>, peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> 
> >In article <1993Jan1.115015.17311@prl.dec.com>, boyd@prl.dec.com (Boyd Roberts) writes:
> >> ...
> >> > A dropped TCP fragment can result in a large amount of resending too.
> >> 
> >> True, but that all happens at the TCP/IP level which is far more
> >> responsive than NFS's 1, 2, 4, 8 ... _second_ exponential backoff
> >> when a datagram gets lost.
> 
> >In other implementations of NFS, the NFS timeout starts at 0.7 seconds
> >not 1.0, and can be reduced to 0.1 seconds.  Please compare 0.1 seconds
> >with the standard TCP timeouts.
> 
> It still doesn't compare very well, at least on paper. With one second
> timeouts and 8K blocks, exponential retransmission ala NFS falls off
> to 50% throughput at an Ethernet packet loss rate of 0.001, and to 25%
> throughput at a loss rate of 0.004. With a 100 mS starting timeout,
> throughput falls to 50% at a loss rate of 0.01, and 25% at 0.025 or
> so. (all figures from eyeballing gnuplot graphs...)

Yes, 1.0 second NFS timeouts are painful.  Even at 0.7 sec, a 1% packet
loss produces a 90% NFS throughput drop, as I have observed from 
involuntary experiments.

But we're not talking about 1.0 or even 0.7 sec NFS timeouts, but about
0.1 sec. NFS timeouts.  I don't know how a 0.1 sec NFS retransmission
timeout would work.  It might be fine with few enough unneeded
retransmissions, since any reasonable NFS server does far more than 10
reads or writes per second.


> With TCP on a local net, however, the retransmission timer should
> adapt to somewhere in the range of say 3 to 6 packet times (correct me
> if I'm wrong...), and so in the worst case (loss rate 0.025, timer = 6
> packet times) the throughput would be about 87%.
> ...

In unmodified 4.3BSD style network code, the "fast" timer runs at 5 HZ,
which means the smallest TCP timer and quickest retransmission you can
have is 0.2 seconds.


Vernon Schryver,  vjs@sgi.com
From: cs@gold.sub.org (Christian Seyb)
Newsgroups: comp.protocols.nfs
Subject: pcnfs 4.0, printing and works
Date: 9 Jan 93 11:39:45 GMT
Reply-To: cs@gold.sub.org
Organization: Unix Mailbox Baldham

Hi,

Some time ago, someone posted a solution for a problem when
redirecting the printer of a msdos pc to a unix host and having
microsoft works installed.

Could please someone mail this posting to me?

thanks and regards Christian
-- 
Christian Seyb      |  Internet: cs@gold.sub.org
-- AT&T is a modem test command ...
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.nfs
Subject: Re: Re: Help with NFS client...
Date: 13 Jan 1993 03:50:26 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <1993Jan12.142939.3773@nic.csu.net> olson@csufres.CSUFresno.EDU (Brian Olson) writes:
>The fact that I couldn't find this nifty little tidbit of information
>makes me feel that my documentation is not the best.  

That's true by definition for most Unix documentation.  The best
documentation is the source code.

The closest the man page comes is this (from rpc.mountd(8)):

OPTIONS
     -n   Do not check that the clients are  root  users.  Though
          this  option makes things slightly less secure, it does
          allow older versions (pre-3.0) of client NFS to work.

What it doesn't say is how it checks that clients are root users.  This is
generally done by assuming that only root users can use ports below 1024
(this is mentioned in the man pages for in.rlogind(8) and in.rshd(8), some
other servers that also have to check that the client is setuid to root).

>						       Could you recommend
>other sources for NFS/RPC info (besides the RFCs, man pages)?  I have
>read about something called the "RPC Programming Guide"--is this
>FTPable?    Also, is there a FAQ for this newsgroup?

I doubt there's much available about implementing NFS.  You might want to
get "Managing NFS and NIS" by Hal Stern, published by O'Reilly &
Associates, for information about how NFS is used on workstations.  Some of
its troubleshooting information may help you understand how implementations
interoperate.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.protocols.nfs,comp.sys.mac.comm
From: Chris O'Donovan <odonovan@physun.physics.mcmaster.ca>
Subject: Re: NFS for Mac
X-Xxdate: Fri, 8 Jan 93 15:57:28 GMT
Organization: McMaster University
X-Useragent: Nuntius v1.1.1d12
Date: Fri, 8 Jan 1993 14:57:40 GMT

In article <1993Jan8.131051.5744@daimi.aau.dk> Lars
Andersen, rodgrim@imv.aau.dk writes:
>But I just read about them because I also need to find a
NFS 
>program. Therefore I would be very grateful if anyone who
own
>any of these programs would comment them. Also I would
appre-
>ciate if there should be a emailaddress for the
compagnies I'd
>like to hear.

I would also like this information.

I would also like to know if there is any way to print to
the Sparc (UNIX postscript) printers on the net.

TIA,

Chris O'Donovan

odonovan@physun.physics.mcmaster.ca
From: don@mars.dgrc.doc.ca (Donald McLachlan)
Newsgroups: comp.protocols.nfs
Subject: NFS implementations for Mac's?
Summary: looking for NFS implementations for Mac's?
Keywords: NFS RPC MAC
Date: 4 Jan 93 16:56:01 GMT
Reply-To: don@mars.dgrc.doc.ca
Organization: Communication Research Centre

We are looking for an NFS client for Mac computers.  Does anyone know whether
this is available commercially or in the PD?

What we are really after is an RPC library, but many people (esp in the Mac world?)
have never heard of RPC.  NFS is built on top of RPC, so we are doing a top down
search.

Any and all input greatly appreciated.

---
Donald McLachlan			e-mail	don@mars.dgrc.doc.ca
Communications Research Centre / DRL	office	613-998-2845
3701 Carling Ave.,			lab	613-998-2423
Ottawa, Ontario				fax	613-990-7987
K2H 8S2
Newsgroups: comp.protocols.nfs
From: geoff@tyger.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Newsgroups: comp.protocols.nfs
Subject: Re: PCNFSD Version 2 source
Date: 12 Jan 93 18:23:54 GMT
Reply-To: geoff@tyger.East.Sun.COM
Organization: SunSelect
NNTP-Posting-Host: tyger.east.sun.com

FTP to any of
	bcm.tmc.edu
	src.doc.ic.ac.uk
	ftpserver.massey.ac.nz

---
Geoff Arnold, PC-NFS architect, Sun Select. (geoff.arnold@East.Sun.COM)
Newsgroups: comp.protocols.nfs
From: hyung@twg.com (Henry Yung (The Last In Line))
Subject: Connectathon '93?
Reply-To: hyung@twg.com
Organization: The Wollongong Group, West Coast Operations
Date: Tue, 12 Jan 1993 00:02:54 GMT



Maybe I didn't get the package in mail but... What's happening with
Connectathon '93?  Is there going to be one?

Hank

-------------------------------------------------------------------------- 
  __  __/  |      /    _____/  Henry Yung	Email: hyung@twg.com
     /     |     /    /        VMS Software Engineering
    /        /  /    / -- /    The Wollongong Group, Inc.
  _/       _/ _/   ______/     Voice: (415)962-7100 FAX: (415)969-5547


Newsgroups: comp.protocols.nfs,comp.sys.mac.comm
From: chchang@ncb.gov.sg (Chang Chen Hsien)
Subject: NFS for Mac
Organization: National Computer Board, Singapore
Date: Fri, 8 Jan 1993 08:05:57 GMT

Hi,

Does anyone know that is there a NFS driver for Mac, so that
I can use my Mac to mount a NFS from the Unix station ?

Thanks !

Chen Hsien
From: jcallaha@willamette.edu (John Callahan)
Newsgroups: comp.protocols.nfs
Subject: PC-NFS Programers Toolkit 4.0
Keywords: pcnfs pc-nfs toolkit
Date: 10 Jan 93 04:53:48 GMT
Article-I.D.: willamet.C0MG9p.2A9
Organization: Willamette University, Salem OR

Has anyone out there in netland had experience with the PCNFS Programers
Toolkit 4.0?  We have version 2.0, but I refused to use it when I noted
that any application you develop loads in TSRs that aren't normally a part
of PC-NFS, so it is obviously not what Sun uses to write PCNFS.

Many of our machines are old, slow, and packed for memory.  I'd like to do
some development with PCNFS but have been frustrated with the tools provided.

If anyone could compare 2.0 against 4.0, or tell me their impressions of
4.0, I'd be very grateful.  Please don't post, I'll post a summary of my
findings.

Thanks!

John Callahan (jcallaha@willamette.edu)
Network Manager
Willamette University
Newsgroups: comp.protocols.nfs,comp.unix.internals,comp.unix.wizards,comp.arch.storage
From: davecb@nexus.yorku.ca (David Collier-Brown)
Subject: Re: duplicate files in NFS directory under heavy load?
Organization: York University
Date: Mon, 11 Jan 1993 13:24:27 GMT

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

|In article <1993Jan10.052211.7018@siswat.hou.tx.us>, buck@siswat.hou.tx.us (Lester Buck) writes:
|> Recently I was told that it is possible, though rare, for typical
|> implementations of NFS servers to return the same entry twice in the ls
|> command.  ....

  This is noticable when doing a ``rename(2v)'' on a systems which
does not give the appearance of atomaticity.  This is easy to demonstrate
on an overloaded sun3 (:-))
  With FFS, you say ``mv foo bar'' and for a brief period there is an entry for
both foo and bar: the creation of bar is atomic, but the deletion of foo
only appears atomic to the caller.  Other processes reading the directory
can aften see both foo abd bar for a brief period over NFS.

  This is only true of **some** ffs implementations: it's easy to make the
whole process appear atomic, as a performance cost. (And yes, I think SGI's
file system avoided the disfeature)


|> Does anyone have any experience with this?  Is this behaviour considered
|> acceptable as long as it is rare?

  No, but it wasn't expected and so wasn't dealt with.  It was an unexpected
cross-product of NFS and FFS implementation decisions.

--dave
-- 
David Collier-Brown,  | davecb@CCS.YorkU.CA | lethe!dave
72 Abitibi Ave.,      | 
Willowdale, Ontario,  | York postmaster and
CANADA. 416-223-8968  | occasional sendfail(8) consultant.
From: jenkinsonjp@rcwusr.bp.com (John P. Jenkinson)
Newsgroups: comp.protocols.nfs
Subject: NFS write error decoding
Date: 5 Jan 93 11:12:44 -0600
Organization: BP Exploration (Alaska)

on AIX i get NFS write errors indicating permission denied. this message has
a string of numbers that i think allow one to find the file by giving
device major minor numbers, inode, etc. can anyone point me to wher i can
find the information to decode these?
Xref: sparky comp.protocols.nfs:3085 comp.sys.sun.admin:10230 comp.sys.sun.misc:6229
From: bradshaw@ccvax.ucd.ie
Newsgroups: comp.protocols.nfs,comp.sys.sun.admin,comp.sys.sun.misc
Subject: LOOKING FOR ASYNCHRONOUS NFS WRITE PATCH
Date: 12 Jan 93 09:59:14 GMT
Organization: University College Dublin

About a year ago, I saw a posting  on  comp.protocols.nfs  outlining  a  patch 
which could be used to enable asynchronous writes to filesystems  mounted  via 
NFS. As far as I can remember, it involved setting bits high, and using adb to 
alter the kernel. At the time, I kept a copy of the patch  posting,  with  the 
intention of using it when I got time. However, now that I have  the  time,  I 
seem to have lost it. I was wondering if anyone reading this would  know  what 
the procedure was, or if anyone would have a copy of that patch.  All  replies 
appreciated......thanks in advance.....My E-Mail addresses follow.....

Chris Bradshaw......

E-Mail:

BRADSHAW@CCVAX.UCD.IE
CBRADH89@IRLEARN.UCD.IE
chris@bermuda.ucd.ie
Xref: sparky comp.protocols.nfs:3075 comp.unix.internals:2106 comp.unix.wizards:5400 comp.arch.storage:908
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.protocols.nfs,comp.unix.internals,comp.unix.wizards,comp.arch.storage
Subject: Re: duplicate files in NFS directory under heavy load?
Date: 10 Jan 93 20:34:08 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1993Jan10.052211.7018@siswat.hou.tx.us>, buck@siswat.hou.tx.us (Lester Buck) writes:
> Recently I was told that it is possible, though rare, for typical
> implementations of NFS servers to return the same entry twice in the ls
> command.  ....


> Does anyone have any experience with this?  Is this behaviour considered
> acceptable as long as it is rare?


No.  No.

(At least it would not be acceptable in one vendor's server or client).


Vernon Schryver,  vjs@sgi.com
From: geoff@tyger.East.Sun.COM (Geoff Arnold @ Sun BOS - R.H. coast near the top)
Newsgroups: comp.protocols.nfs
Subject: Re: need help mounting pc disk on sun with soss
Date: 7 Jan 93 21:46:28 GMT
Reply-To: geoff@tyger.East.Sun.COM
Organization: SunSelect
NNTP-Posting-Host: tyger.east.sun.com

In article 18589@progress.com, peterl@progress.COM (Peter Lauterbach) writes:
##	I'm trying to mount the PC disk on the sun, using the pd version
##nfs server soss, with a packet driver.  I can ping the PC from the sun , 
##showmount -e pc , show that the c: drive is ok for export.  However, when I
##try to mount the disk using:
##
##	mount -t nfs -o <option> pc:/c /usr/soss
##
##I get the message on the sun : RPC: program not registered
##
##and on the PC:
##PMAPPROC_GETPORT prog 100005 vers 2 no port registered
##

This means that the Sun tried to use version 2 of the mount protocol
and the server didn't support it. 

I don't have the SunOS 4.1 sources on-line. In 4.1.1, mount.c includes
logic to back off and try again with a lower version (it uses
clnt_create_vers() to find out what versions are supported). The
comment indicates that this was a bug-fix, but doesn't provide any clue
as to when the fix was applied.

Workarounds: fix SOSS to support version 2 of the mount protocol (which
is very straightforward - has anyone done it?), or upgrade to SunOS
4.1.x (which will probably cost $$$).


---
Geoff Arnold, PC-NFS architect, Sun Select. (geoff.arnold@East.Sun.COM)
From: mik@hpbbi4.BBN.HP.COM (#Michele Isernia)
Date: Thu, 7 Jan 1993 10:51:28 GMT
Subject: NFS versions compatibility ?
Organization: Hewlett-Packard GmbH
Newsgroups: comp.protocols.nfs

Hi,

I'm looking for any document discussing compatibility and
interoperability between the varius NFS versions...

I will relly appreciate any help..

Pls. reply by e-mail directly..

mik@hpbbn.bbn.hp.com

Mik
Newsgroups: comp.protocols.nfs
From: pruett@CS.ColoState.EDU (J. L. Pruett)
Subject: PC-NFS & 3C503/telnet
Date: Tue, 05 Jan 1993 17:00:44 GMT
Organization: Colorado State University, Computer Science Department

I have been updating a 286 pc with a 3c501 ethernet card to a
386pc with a 3c303 card. Apparently, I've ran into mutual exclusivity.

If I load the Clarkson packet driver for the 503 card, the NFS
stops working correctly. If I don't load it, the NFS works fine,
but the telnet process won't work (obviously, no packet driver installed).

Any suggestions? The driver looks like 3c503 0x60 5 0x300.

Thanks,
Jenny

Newsgroups: comp.protocols.nfs
From: wezel@bio.vu.nl (Jos van Wezel)
Subject: Re: NFS for Mac
Organization: VU Biology, Amsterdam, The Netherlands
Date: Tue, 12 Jan 1993 00:51:17 GMT

Which reminds me: Is is the current version of NFS-Share still 1.2? The product
needs some refinements badly including a recently discovered security bug.

People at Intercon are you listening?

I'm using NFS-Share a lot because it is fast (compared to GatorShare) and
has the ability to select the UNIX mount points (though this indeed is a
administrators nightmare quoting 'wdburns@walker2.hu.mtu.edu (BURNS)' :-) )
Some automatism could be introduced while retaining the full configurability
for people who want it.

What a like most, speaking as a system administrator, is the builtin rwall
receptability. Sadly it crashes your Mac.

As a whole I think it is the BEST solution for Mac networking in a UNIX
environment. The current state however, makes it difficult to introduce it in a
large user community. So we stick to our 2 copies for the time being.

As for the other products: 
GatorShare: sloooooooow, only 5 - 6 users at a time, easy to manage.
Wollongong: it's not Mac alike, use NFS-Share.

Jos van Wezel
System Administrator
---------------------------------------
									  ----------------------------------------
Newsgroups: comp.protocols.nfs
From: jbvb@vax.ftp.com  (James B. VanBokkelen)
Subject: Re: NFS packet size
Nntp-Software: PC/TCP NNTP
Keywords: TCP NFS
Reply-To: jbvb@ftp.com
Organization: FTP Software, Inc., Wakefield, MA
Date: Tue, 05 Jan 1993 18:36:18

In article <51022@shamash.cdc.com> gsa@easyaspi.udev.cdc.com (gary s anderson) writes:

    I'm not sure about your version of TCP, but 1 sec tends to be a
    nominal value for determining when to retransmit.  You must also
    accommodate "delayed acks" (200 msecs comes to mind for this value)
    when determining when to retransmit.

In a good TCP, 1 sec. might be the initial value before any packets
are exchanged, but the only way it would persist after the connection
open would be if packet loss was such that you didn't get *any* clean
send/ack cycles (without retransmits).  A TCP might wait 200 ms.
after receiving a single short segment, but it ought to issue the ack
as soon as the RHS of the window should be moved (see RFC 813).  This
means that it normally won't dally when bulk data is being moved, and
even if the last packet is small enough that a dally occurs, the ack will
not wait any longer than the time to complete & reply to the RPC.
    
    You will also discover that NFS has an interesting delay pattern when
    using TCP because of "delayed acks" (i.e. the last packet
    is not a full MSS).  Disabling Nagle's algorithm does eliminate this delay
    (some implementations allow you to do this).

Many versions of 4bsd TCP don't really have a correct implementation of Nagle.
Nagle says that if there is no unacknowleged data in the retransmit queue,
send the segment regardless of size.  4bsd chose to wait rather than send a
short segment when nothing else is outstanding.  This produces the behaviour
you describe, and may well vanish if you "disable Nagle", but Nagle himself
isn't to blame.
    
    Is there some major point that needs rehashing?
    
The fact that TCP largely de-couples the network RTT from the server's
disk is not anything I'd heard before, but that doesn't guarantee it's
new.

James B. VanBokkelen		2 High St., North Andover, MA  01845
FTP Software Inc.		voice: (508) 685-4000  fax: (508) 794-4488

Newsgroups: comp.protocols.nfs
From: bud@cbnewsm.cb.att.com (jean.f.zaleckas)
Subject: Re: PCNFSD Version 2 source
Organization: AT&T
Date: Mon, 11 Jan 1993 19:28:44 GMT
Summary: PCNFSD

In article <1993Jan07.221942.15307@catfish.az05.bull.com>, brunelle@az05.bull.com (Edward C. Brunelle Jr) writes:
> Does anyone know where there is a copy of the PCNFSD source code for a
> version 2 daemon?  


I would also like a copy of the PCNFSD ver2 daemon. Is this code available
on the internet somewhere? 

-Jean Zaleckas
AT&T
Xref: sparky comp.protocols.nfs:3088 comp.sys.sun.apps:2952 comp.protocols.tcp-ip:5938