Greetings,
I did not have time to really track this down because I had a
workaround. It seems that applying patch 101945-27 helps somewhat, and
also that performance can vary from system to system and using the "-n"
flag to rsh usually makes things go faster. However, I could not seem
to get consistent results so now I use NFS which is much faster than
rsh...tar anyway. The only drawback of this is that the directory to
be copied must be NFS-mountable.
The end result is that there still is a problem, and maybe Sun will get
around to fixing it in 2.5, 2.6, etc., or maybe patch 101945-53 or -167
or so. :-[
Thanks go to:
Casper Dik <casper@Holland.Sun.COM>
lilga@srv630.Ando.Com (Dave Lilga)
Boyd Fletcher <boyd@ccpo.odu.edu>
jgarb@erim.org (Joe Garbarino)
jamervi@sandia.gov (1236 Joseph A. Mervini)
epl@caps.kodak.com (Gene Loriot (epl@kodak.com))
Dan Lorenzini Greenwich Capital Markets
dal@gcm.com 600 Steamboat Road
203-625-6088 Greenwich, CT 06830
------------------------------------------------------------------------
Original message:
A command that I sometimes use to copy directory trees from one machine
to another looks like this:
rsh -n <machine> "(cd <directory>; tar cf - .)" | tar xBpf -
I have been doing this under SunOS and the throughput has been
acceptable (roughly 500k/s or better).
I recently did the same command from a Solaris 2.4 system with a SunOS
4.1.3 host as the remote machine. The throughput was abysmal: roughly
50k/s, or one-tenth the normal speed.
In this particular case, since the source directory was NFS-mountable, I
reworked the command to be:
(cd <NFS pathname>; tar cf - .) | tar xBpf -
and it went much faster (roughly 750 k/s). However, I am worried that
in the future I may want to copy stuff that is not exported so this
workaround will not be as easy to do.
I assume that since the Solaris system does not have a problem with the
high throughput, that there is some mismatch between Solaris and SunOS
that is causing rsh to operate inefficiently. Does anyone know if there
are some tunable parameters I could use to rectify this situation?
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:31 CDT