Oops, my eyes missed the pipe and second dd when I made my previous
comments. That is pretty good for different disks then yes... not
so good for same physical disk.
Indeed my tests were done copying from the "old" disk
to the "new" disk, as the OP is doing, I believe.
I actually have some old hacked up dd code I made once to use 16
concurrent aio requests with O_DIRECT. I need to clean it up a
bit but it showed great promise.
Considering how often "dd" is used for copying large amounts
of data, even a modest improvement could save many thousands of
hours of admin time. I would like to encourage you to do any
needed cleanup and make it available, preferably integrated with
GNU dd - it could save hundreds of thousands of dollars worth of
time.
--
Ray Morris
support@bettercgi.com
Strongbox - The next generation in site security:
http://www.bettercgi.com/strongbox/
Throttlebox - Intelligent Bandwidth Control
http://www.bettercgi.com/throttlebox/
Strongbox / Throttlebox affiliate program:
http://www.bettercgi.com/affiliates/user/register.php
On 04/21/2010 11:27:22 AM, Phillip Susi wrote:
On 4/21/2010 11:36 AM, malahal@us.ibm.com wrote:
> Interesting! You are doing direct I/O to avoid copying from cache
to user
> buffer for read and vice-versa for write, but you are losing the
ability
> to do them parallel! You are doing the next best, that is creating
two
> "dd" threads -- one for reading and another for writing. Since the
pipe
> is really implemented in memory, why should this be faster than
normal
> "dd" that uses page cache? Likely that kswapd is not kicking early
> enough?
Oops, my eyes missed the pipe and second dd when I made my previous
comments. That is pretty good for different disks then yes... not so
good for same physical disk.
> Enhancing "dd" to create a reader and a writer thread would really
> help, I believe.
I actually have some old hacked up dd code I made once to use 16
concurrent aio requests with O_DIRECT. I need to clean it up a bit
but
it showed great promise.
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
