From: "Antti Kurenniemi" 

"Mike N."  wrote in message
news:8eh042pibmg1loncd5tb126hs09sg3gama{at}4ax.com...
> On Fri, 14 Apr 2006 21:14:25 +0300, "Antti Kurenniemi"
>  wrote:
>
>>4. Push the piece into the destination stream, while continuing to read
>>from
>>the source stream.
>
>   I think we're saying the same thing - this is simultaneous operation,
> whether from multiple threads or overlapping I/O.   Described this way, it
> seems quite likely that CopyFile() uses simultaneous I/O in the copy
> operation.

Yeppers - it's just not multithreaded really, that's what I meant. That's
what I originally meant, that the basic copy routines of today's Windows
versions are good enough that they cannot really be made faster by using
other software, as it's the hardware that's the slowest part of the chain
in any case.

Oh, btw, this doesn't apply in all cases. For example if you copy a huge
load of small files into a USB drive, it takes ages, but if you have a
single file of the same total size, it is a thousand times faster. Seems
that there is waiting there; the source disk probably waits until the file
is completely written to the destination until it starts sending another
one. I don't know this for sure, but it's probably because of the
"yank-the-plug-at-will" nature of USB that makes this a sensible
thing - that way you can't break more than one file no matter how hard you
try. Also, if moving files instead of copying, it is important to get the
all clear signal from the destination disk before deleting the original.

So, if copying a lot of data to a USB drive, zip first, then copy. I do
this quite a bit (source code files - a lot, and they're generally small),
and sometimes I don't zip the files and oh man it is annoying to wait for
it, wait for it... wait... for... 


>   FYI - we did the upgrade  this morning at 4:00 AM.  RoboCopy worked
> perfectly.   It appeared that the read operation kept the source drive 95%
> occupied, and the target drive 50% occupied, judging by the lights.  It
> would have been interesting to put some NT performance counters on that,
> but there were many things happening at once.....

The speed difference of the disks is most likely just the write buffer, and
that the writing disk was probably empty (was it?), so it was not required
to look for empty blocks where to write data but could just lay the blocks
out as it got them.


Antti Kurenniemi

--- BBBS/NT v4.01 Flag-5