🚀 go-pugleaf

In article <92233.194824RONY@awiwuw11.wu-wien.ac.at> FLATSCHER Rony <RONY@awiwuw11.wu-wien.ac.at> writes:

>2)
>
>NFS-Server started on OS/2, mounting exported OS/2-drive from DEC-ultrix.
>
>ls works, copying with cp or accessing OS/2-files with unix-programs
>lead to troubles in OS/2-NFS-server not replying. The unix-side retries,
>occasionally files get thru to the Unix-side.
>
>The OS/2-NFSD-screen shows:
>
>IBM OS/2 NFS Server Version 1.0 (Mar 12 1992)
>
>NFS: File ownership set to uid ...., gid .....
>NFSD: Initialization complete.  Server running.
>NFS<_nfsRead>: Can't send reply
>NFS<_nfsRead>: Can't send reply
>... a couple of times the above message

This indicates that the NFS server couldn't transmit the reply to the client's
remote procedure call - thus the timeout errors you are seeing on the client
side.  What is most likely happening is that the RPC reply NFS is trying to
form is exceeding the allowable UDP packet size that the TCP/IP kernel can
transmit.  This size varied a bit with different releases of the kernel.  In
theory, you should be able to transmit 8K data buffers, but I've known
different kernels to have lower limits.

Odds are that your Ultrix side of the coin is configured to use 8K read
and write buffers.  Try lowering those buffers and see if things improve.
I'd suggest trying 4K just to see if it works, and then increasing the
read buffer until it stops working (you'll probably get to somewhere in the
7K range).

I would recommend leaving the write buffer at 4K since at larger sizes it
can overrun the OS/2 machine, and you get involved in retransmission timeouts
that grow exponentially.  Sometimes, writing a file from a fast box to a
slower box over NFS can be 10x slower if you use too large a buffer size.

>As we intend to backup all of our OS/2 machines via the Unix machine
>(it has an exabyte streamer) we would need the NFSD being stable. Unfortunate-
>ly, the IBM-version of TCP/IP does not have a tar supplied (which could be
>EA-aware). Does FTP's OS/2-version include it as is the case with the DOS
>version ? Does IBM intend to add a tar in the near future ?

This setup should definitely work - I've been backing up OS/2 machines to Unix
tapes (on RS/6000s) using tar for a bit over 2 years now and have used the
backups for restoration a number of times.  Unfortunately, I don't know of a
good solution to the EA problem - for my purposes the files I back up don't
have any critical EAs, so I have to admit to ignoring the problem.  I also
don't try backing up system files like OS2.INI, etc..

EAs are a bit of mess from an NFS point of view - there just isn't any clean
way to try to support them using the NFS protocol such that normal
applications on hosts communicating with NFS understand them.  Rather than
"network" file system, NFS should really have been titled "unix network" file
system, as the protocol is very tied to the Unix filesystem structure.

Another possibility is that with a little work, I'm sure the current GNU tar
that runs under OS/2 (which does understand EAs) could be set up to work
properly with the IBM TCP/IP package (or any other that supplies an rsh or
rexec (I won't forget you guys Larry)).

It's not an immediate (ala tomorrow) solution, but may be workable.

--
-- David
--
/-----------------------------------------------------------------------\
 \              David Bolen             \  Internet: db3l@ans.net      /
  |   Advanced Network & Services, Inc.   \   Phone: (914) 789-5327   |
 / 100 Clearbrook Road, Elmsford, NY 10523  \   Fax: (914) 789-5310    \
\-----------------------------------------------------------------------/