simultaneous copy to multiple media
Bengt Richter
bokr at oz.net
Mon Mar 21 20:12:40 EST 2005
On Mon, 21 Mar 2005 17:53:34 +0100, Jacek Trzmiel <sc0rp at hot.pl> wrote:
>
>> > This is small tool I've wrote, that does use large memory buffers with
>> > asynchronous I/O to copy file.
>
>Claudio Grondi wrote:
>> Thank you!
>> This (with a drawback of blocking the entire system) does it!
>> ( dzieñ dobry i dziêkujê za t± konstruktywn± odpowied¼
>> na moje pytanie )
>
>:)
>
>> From my point of view this thread has reached
>> its end (I have a solution I can live with), except if
>> someone would like to contribute or point to a
>> better multicopy.exe which does not block the system
>
>Symptoms (high cpu usage, unresponsive system) look similar to situation
>when you try to read/write as fast as possible from/to IDE drive running
>in PIO mode. I think that it's either USB driver problem, or inherent
>design flaw in USB (anyone?).
>
>Anyway, I've added buffersize and sleeptime options to multicopy, so you
>may try to throttle it down. Download it here:
> http://mastermind.com.pl/multicopy/
>
What if some disks could benefit from running ahead a few buffers while others
are hanging slowed by e.g. allocation and seeking activity? ISTM there could be
a benefit to keeping a multibuffer readahead window of the source stream going?
(I didn't look at your code, maybe you do this? Also maybe a particular OS might
do this for you so that using several open source streams coming from the same datafile
would automatically share system readahead buffer info if reads stayed within
a few buffers of each other. Do you us multiple open readonly files as source streams?
Or are OS file systems so dumb they don't notice shareability of temporarily
memory-resident readonly file data buffers? I guess it would vary, and you could
lose or gain by single or multifile source strategy, depending ;-)
Regards,
Bengt Richter
More information about the Python-list
mailing list