Text 10725, 65 rader
Skriven 2006-04-14 21:14:24 av Antti Kurenniemi (1:379/45)
  Kommentar till text 10723 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:2gev32985nehle8jsos7d9nmhpu266nrnf@4ax.com...
>>Yes but that's what the buffer memory in the drive is for, no need to try
>>to
>>implement a second buffer in the OS level.
>
>  Visualizing what the CopyFile routine does:
>
> R=read
> W=write
> I=idle
> S=Source Drive
> D = destination drive
>
> S D
> R I Start reading file 1
> R I
> R I   File1 completely read from source
> I W Start writing file 1
> I W
> I W File1 completely written to target
> R I  Start reading File 2
> R I.....
>
>  With a single threaded model, one of the drives is completely idle for
> half the time.     I don't know if CopyFile is internally multithreaded.
> In
> the normal case when the source and target are on the same device, it
> might
> not make sense to have it multithreaded.   When copying drive to drive it
> could clearly benefit.

No, it doesn't work like that. It starts writing to the second drive as soon as
there is some data in the read buffer from the first file. Think about it, if
file 1 was completely read before starting to write, you'd never be able to
copy files that are larger than your free memory size. And if you copy a large
file, do you see your memory size increasing? No, you don't, because what
happens is:

1. Open a stream to read from (source file). 2. Open a stream to write to
(destination). 3. Read a piece of the file from the source stream (block sile,
512bytes or whatever it happens to be in the system). 4. Push the piece into
the destination stream, while continuing to read from the source stream.
5. Repeat until read the file, and then go to the next file. Note, that here
the file may not yet be completely written to the destination, as several
megabytes may still be in the write buffer of the destination disk

The only case where the file read would be interrupted is if the disk to write
to (or the write operation to be more precise) is slower than the disk to read
from, in which case the write buffer is filled. And the other way around, if
the write operation is faster (newer disk for example), the reading part will
force writing to wait. Neither of these cases will be helped by multithreading.

Old systems worked like you describe - I think NT4 did something like that,
which was a real pain if you copied something over the network because it would
open and close the stream for each file. But W2k and later are quite a bit
better at this.


Antti Kurenniemi

--- BBBS/NT v4.01 Flag-5
 * Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)