John,

> I have established that the NWorker server communicates to the Netware
> client via RSH, and have been advised that in this storage node config, the
> backup data will be transported via RSH from the clieint to the NWorker
> server, and then to he Storage Node, and that RSH is a relatively
> inefficient protocol, not designed for heavy file transfer like backups,
> hence the low performance.
>
> Can anyone confirm that this conclusion is correct?

AFAIK it is not entirely correct.

The NetWorker server contacts the client (your Netware server) via rsh
like you say (this is because the client for Netware is so old that it
doesn't understand the newer nsrexec method).

This contact is only to get "save" running on the client.  The rsh
connection will transport stdout and stderr from the save back to the
server (which includes all the error messages, as well as file names if
you used -v), but not the data stream.  In other words, a relatively
small volume of data.

You can use any method you like to run save on the client; you are not
restricted to savegrp, though this would probably be the most common
and most convenient method.  You could, for example, run it manually -
it would still work the same way (I'm not a Netware person so don't ask
me how to do this...).

Once save has started (via whatever method) it contacts the server
directly and does its stuff.

> If so the implication is that Netware clients are NOT going to work with
> Storage Nodes at any acceptable trasfer rate, yes?

Netware clients are not going to work with storage nodes, but for a
different reason.  The Netware client code is so old that it doesn't
understand about storage nodes (this seems to be a recurring theme -
question: do you pay the same for annual support for the Netware
clientpak as you pay for other OS clientpaks?  Do you get the same
level of support?)

The workaroud here was to start an agent on the server for the old
client to talk to.  This effectively translates the old style requests
into the new style, and keeps everything relatively happy.

This seems to work OK (albeit slowly) for saves to storage nodes.  It
does not seem to work at all for recovers from storage nodes.  (This
was all implemented in the days when Legato, and others, seemed to ship
product with minimal testing - it is possible that it has never been
tested.)

> Does anyone know if this is likely to change in the near future?

Going by past performance it is not likely to change even in the
distant future.  OTOH, the EMCC takeover might fix this.

George.
--
George Scott           George.Scott AT its.monash DOT edu
Systems Programmer, IT Services, Monash University

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=