Text 10733, 54 rader
Skriven 2006-04-15 11:01:22 av Antti Kurenniemi (1:379/45)
  Kommentar till text 10729 av Mike N. (1:379/45)
Ärende: Re: Fastest way to migrate Drive -> Drive??
===================================================
From: "Antti Kurenniemi" <NOantti@SPAManttikPLEASE.com>

"Mike N." <mike@u-spam-u-die.net> wrote in message
news:8eh042pibmg1loncd5tb126hs09sg3gama@4ax.com...
> On Fri, 14 Apr 2006 21:14:25 +0300, "Antti Kurenniemi"
> <NOantti@SPAManttikPLEASE.com> 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... <g>


>   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
 * Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)