I suppose you want to preserve absolutely everything: files, ownerships, filemodes, ...
I do that (out of habit - presumably there are other equally good ways to do it) using two tar's and a pipeline:
# cd /path/to/sourcedir
# tar -cf - . | (cd /path/to/targetdir ; tar -xf - )
The first tar packs everything to <stdout>, the second one unpacks from <stdin>, this is what the "-" stands for. If you include a "-v" to one tars options you can even watch the progress (at a small expense of performance of course).
Yes, this will work, regardless of the number of files.
You could use "dd" too, but i would prefer to use an "high-level" approach when possible instead of a "low-level" approach such as "dd". With "dd" it is easily possible to overwrite not only files, but devices, volume group information, things quite vital to your system.
With "tar" you deal with files, directories and the like - things which are easily recognized by you. With "dd" you ultimately deal with devices, which is much more dangerous. If you mistype "/tgtpaath" in the above mentioned "tar" command you will run into a "disk full"-error, have the chance to correct it and start over. If you confuse hdisk127 and hdisk126 in a dd command it will work well but probably destroy data you didn't want to lose.
That doesn't mean at all that "dd" is a bad tool - it is very powerful, but the power comes at the price of being dangerous too. Use it when you need it, not when it is possible, is my principle. Maybe i'm feeble, but i have been working as a Sysadmin for a long time and i am still alive. ;-))
Are /sfsapp and /tgtapp mountpoints?
Is there anything in /tgtapp already?
Though you don't mention the version of AIX or anything about the hardware of the disc system, do you have an AIX version which can deal with files larger than 2 Gb ?
The usual solution is to use "find" piped to "cpio -p" .
e.g.
cd /sfsapp
find . -xdev -print | cpio -pdumv /tgtapp
Quite frankly, i don't understand your obsession with "dd", given that you have been offered several good alternatives. You will not gain anything by using "dd", not speed, not ease of use and definitely not safety. To me that starts to sound like homework.
Here is your solution, use at your own risk, i haven't tested it.
First find out the devices which are mounted at the respective mountpoints with the "mount" command, then use these devices as infile and outfile of "dd".
Example: copy "/ap101" to "/ap102".
# mount
node mounted mounted over vfs date options
-------- --------------- --------------- ------ ------------ ---------------
<...SNIP...>
/dev/lvap101 /ap101 jfs2 Nov 29 11:33 rw,log=/dev/logapdev1vg
/dev/lvap102 /ap102 jfs2 Nov 29 11:33 rw,nodev,nosuid,log=/dev/logapdev1vg
<...SNIP...>
# dd if=/dev/lvap101 of=/dev/lvap102 bs=512
I have no idea about your disks performance, but a quick estimation tells me: if the target disk can write at 20MB/s continuously then it will take (250.000/20=) 12500 seconds to write 250GB - 12500/3600 ~ 3.5 hours. I doubt your disk (LUN, whatever) can write at the ~140 MB/s (continuous!) necessary to finish the job in 30 minutes.
Could you be bothered to read the man page of "dd", after insisting on this tool, before asking here? It tells you that it has - until you cancelled it - 2352183 pieces of the size given in the command in option "bs" read and written as many. As you issued
dd if=/dev/sfsapplv of=/dev/tgtapplv bs=512
it read 2352183x512=1204317696 bytes and wrote as many.
Again, i don't think it is advisable to use "dd" for that task (even more it is dangerous in the hand of someone not completely knowing what he is doing) and i won't answer questions easily answered by looking at the man page again.
You haven't said so until now. If so, what exactly was the error? The method i described (tar) has worked for me countless times, also on such amounts of data and even more.
Using "backup" and "restore", "cpio" or "savevg" will equally work and probably at roughly the same speed as "tar".
One thing though: you can't cancel a job after some time and expect it to have finished the task - if you have to cancel it that means it was still running and if it was running it means it hasn't finished what it was doing.
I don't know AIX, but with the OS's I know unmounting the destination prior to running the dd is a must. I would unmount the source as well if I could. This is one of several reason why a dd in this case is not a great idea.
The below command worked but after 3 hours finished but the data is not completed.
whole data in the source mount porint is 80% after finish the copying data came in the target mount porint as 30%
cd /sfsapp
tar -cf - . | (cd /tgtapp ; tar -xf - )
guy's
I'm looking for strong command dd or cp ... etc whatever I want to copy these huage data to the anothere mount porint ..
You can throw a -P in there which will show progress and a -n will give you a dry run to so you can see what it would look like before a real run. Also a -v if you want verbose output.
This sounds quite suspicious. Could you please post the AIX version you are using (and, if applies, if you are using a 32-bit or 64-bit version?). This sounds like an older version not capable of dealing with files larger than 8G (ustar) or maybe hitting a 2G file size limit.
While you are at it: output of "ulimit -a" might also be interesting.