Solaris

When copying data via ssh pipe, always add "-e none" to the command in case any characters in the stream match the ssh escape characters:

Code:

tar cf - ./path/to/files | ssh -e none special_user@remoteserver ' cd /parent && tar xBf - '

This is really moot, though, until we get more details from the original poster.

@achenle: the OP specified 3 Mio (3 million) files that are on average 1 KiB in size, so that should be in the order of 3 GiB. With a SATA disk with 120 (sequential, but small) iops, so with a 1KlB IO Size that should then theoretically be 3,000,000 IOS / 120 IOPS = 25000 seconds, i.e. around 7 hours for the data alone, limited either by the reading or the writing system (probably the writing side is faster since the IO's will more sequential in nature). This is excluding the IOPS required for the metadata. If the filesystem can do write combining / prefetching then perhaps that may be a bit more efficient. If the filesystem has a larger minimum block size, then that would not matter much for speed, since the block size would still be smallish.

When we take the disk out and put it in the other server we need another stream and the same amount to copy it to the disk on to the other server plus sneaker time..

If we would use the netwerk, we would probably not need much more time and we could do it with a single stream, reading from one computer, writing onto the other (the network would not be a bottleneck here..)... So that should take in the order of half the time..

If we we use any of the block copy methods in my post, there would be no need to copy the files individually nor all that metadata manipulation and can read large chunks of data with big IO's (for example 1 MiB per IO) which will be significantly faster probably in the order of 100MB/s so it should theoretically take in the order of 30-60 seconds for the data alone, if the network is not a bottleneck...

Of course if the data is on a large filesystem then that whole filesystem would need to be copied unless the method is smart like filesystem dumping methods or ZFS send / receive, which only copy the parts that are in use..

So that's what "mio" means...

120 IO operations per second from a SATA drive is quite optimistic. A single 7200 rpm SATA disk is realistically more likely to get about 60-70 IO operations per second, because the small reads in this case are not likely to be sequential - they'll effectively be random IO operations. If it's a 5400 rpm disk, the number would be even less.

And if atime modification isn't turned off, every read operation that reads a file will generate a write operation to update the inode data for that file.

So that's probably somewhere between 6 and 9 million IO operations because metadata has to be read to even find each file. Call it 6 million IO operations, and assume the disk can do 60 IO operations per second. That's 100,000 seconds, More like 28 hours. And that assumes the disk isn't servicing other IO operations.

Why not just share the file system via NFS and let other systems access the files that way.

Well, given our lack of information, there is no real answer.

IOPS are not knowable - our SAN does 12000 iops continuously if required. The sata disk on my desktop does maybe 70. And if the file systems were zfs and were on a SAN, then the "copy" time is the time it takes to type four or five zfs commands.

So maybe we are are comparing apples to elephants. Do not know.

In any event, when an app (or a user) is allowed to clutter a filesystem as described, there is not a lot of hope for it. A simple find or ls command can take hours to complete. On some systems. Copying it as is does not seem like a best practices idea to me.

cpio in pass through mode is generally regarded as being much faster than tar.