Solaris

This might be better, as it won't run into globbing issues if there are too many files, and it will copy hidden files/directories too:

Code:

cd /source ; tar cf - . | (cd /target ; tar xf - )

But it probably won't be any faster than cp anyway.

The real solution: buy faster disks.

True, but my point was rather to suggest the general idea than to provide a watertight solution. I could have written by creating an I/O-stream (via tar) from the various files and using the restore-part of tar instead of single-threaded file-I/O as with cp it might be - probably depending on the exact implementation of tar - a bit faster than using cp as well.

Yes, i could be mistaken and i don't have any prior experience with copying this much data (the only times i had to move so much data i did it with SAN-methods, foregoing the OS completely). It is just - IMHO - worth a try.

At any rate: you surely are correct that in using different storage technologies - faster disks, tiered storage, etc., in other words changing the underlying physics - will have more effect than anything even the most clever OS trick can hope to achieve.

bakunin

Hi.
It made a difference in this informal test for a 2 GB file: Simple speed comparison between cp, mv, and rsync | RothWerx

That, however, was not zfs (probably).

Best wishes ... cheers, drl

The OP has not specifed the filesystem / mirroring techniques / external disks he is using.
This information is essential, as well as what the actual objective is in more detail.

Most filesystems have atime on by default, this will cause the system to update atime property for each file accessed.
Will slow things down causing more i/o.

For SVM ,It is just faster to mirror / break mirror approach for initial copy, followed by a incremental using rsync if you need to traverse the data.
rsync is a great and versatile tool, with many options, from which i especially like --link-dest when using hard links.

For ZFS locally i would make a attach of new disk on current setup if possible (three way mirror for instance, from 1+1).
Why mirror, well zfs will copy only used data and in turn check your data for corruption in the process. Wonderfull isn't it
After the mirror completes, you do a zpool split and data is available for mounting on that on any other system (for fc, iscsi..)