rsync shows poor throughput vs. scp

[Tony Abernethy]

Marty Mulligan  wrote:

 Thanks for your suggestions.  I'll try to put together an rsync call with a
more explicit set of options, although I was under the impressions that by
having the "dont compress" option set in the conf file on the server, the -z
option in the call from the host was ignored (which begs the question, "why
the -z in the call from the host?" :) )


    (I suspect that here is a case where you use rsync because it's easier
to figure out rsync
    that to use something (actually quite different) that is more
"appropriate".




  hmm... ok, I am open to suggestions!  What do you recommend that would be
more appropriate?  One thing I am currently investigating is "File
Alteration Monitor" or fam, which was alluded to somewhere in this lists
archives.

  The "something more appropriate" is something you design and write
yourself.
  And you get to debug it yourself. Including all the little suble thingees
which are there and do matter.
  They are at least theoretically possible.
  I wouldn't say I recommend them.
  If everything goes perfectly, a lot of things are equivalent.
  It's when things mess up in the middle, what is the resultant state? What
should it be?
  This is really a question of which errors do you commit (to try to avoid
other errors)

  Question: how long does it take to write a file to disk?
  Answer: It depends  ... actually on EVERYTHING that is going on DURING the
write.
  Generally disk is written much faster if it is written sequentially.
  One way to slow it way way down, it to interrupt the stream of writes with
a bunch of (any) disk IO elsewhere on the disk.

  You should realize that disk is called random access, but is in fact
anything but random.
  Like scheduled trains or busses or airplanes, the place under the heads
that is to be read or written comes up very predictably. This means that
tiny changes can have big consequences. Miss a flight by a few seconds and
wait for the next day (or week or ...).  Most likely you have the drive
reading in one place and writing in a different place and the seek time has
a significant impact on what happens.
-------------- next part --------------
HTML attachment scrubbed and removed