[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Another rfe: "cp" this time
From: |
Bruce Korb |
Subject: |
Re: Another rfe: "cp" this time |
Date: |
Fri, 27 Apr 2012 11:02:20 -0700 |
Hi,
2012/4/27 Pádraig Brady <address@hidden>:
> Just to be clear, you started with cp, went home, resumed with rsync.
> So rsync is not faster here, as there is no remote rsync server.
Exactly. rsync has a "resume" and that is faster than starting over. :-D
> Note you could test your multiple readers idea simply like:
>
> (
> dd bs=32KiB skip=0000 seek=0000 count=1000 conv=notrunc &
> dd bs=32KiB skip=1000 seek=1000 count=1000 conv=notrunc &
> dd bs=32KiB skip=2000 seek=2000 count=1000 conv=notrunc
wait
> ) > /local/file < /cifs/file
>
> A simple wrapper could be used to start the correct number of dd processes.
Hadn't thought about using multiple dd processes. (The last "dd" needs to
lose that count option tho.) Somehow "dd" didn't jump out as the obvious
way to copy files across a high latency link. :) Thanks.
That kills the priority for this for me, but I still think --parallel
is useful.
Multiple concurrent dd processes managed by yourself seems like a
cumbersome way to go. Cheers - Bruce
- Another rfe: "cp" this time, Bruce Korb, 2012/04/27
- Re: Another rfe: "cp" this time, Pádraig Brady, 2012/04/27
- Re: Another rfe: "cp" this time, Bruce Korb, 2012/04/27
- Re: Another rfe: "cp" this time, Pádraig Brady, 2012/04/27
- Re: Another rfe: "cp" this time,
Bruce Korb <=
- Re: Another rfe: "cp" this time, Pádraig Brady, 2012/04/27
- Re: Another rfe: "cp" this time, Bruce Korb, 2012/04/27
- Re: Another rfe: "cp" this time, Bruce Korb, 2012/04/27
- Re: Another rfe: "cp" this time, Bruce Korb, 2012/04/30
Re: Another rfe: "cp" this time, Bruce Korb, 2012/04/27
Re: Another rfe: "cp" this time, Andreas Schwab, 2012/04/27