Solved How do I see progress when cp or mv big files?

Try Control-T. For most programs, it prints out system statistics: How much CPU time used, memory footprint, how many IOs done. Programs can catch the underlying signal (SIGINFO) and print more meaningful statistics. I think FreeBSD's version of dd does that; don't know about cp and mv.

If you want overall speed info, tools such as top, vmstat and iostat are good starting points.
 
mv(1) would be nearly instant if the file was moved/renamed within the same filesystem.
 
With net/rsync you'll be able to see the speed and the current state of the transfer.
Code: 
$ rsync -a --info=progress2 dir1/file_1.txt dir2/
              0 100%    0,00kB/s    0:00:00 (xfr#1, to-chk=0/1)
Create an alias or a function in your beloved shell rc file for more comfort.
alias copy='rsync -a --info=progress2'

Then you'll end up with:
Code: 
$ copy dir1/file_1.txt dir2/
 
SirDice said:
Was about to mention it. If you need to copy or move a large amount of files then rsync(1) is probably a better idea.
Click to expand...
There is another reason to use rsync: A few years ago (by now, probably 10 years ago!) it had the best algorithm for detecting sparse files, and copying them appropriately. Now in real-world use sparse files are rare, but if you have them, one can save a lot of disk space and copying time by doing so appropriately.

Never mind ... see cracauer's post below; rsync does NOT do the efficient thing.
 
ralphbsz said:
There is another reason to use rsync: A few years ago (by now, probably 10 years ago!) it had the best algorithm for detecting sparse files, and copying them appropriately. Now in real-world use sparse files are rare, but if you have them, one can save a lot of disk space and copying time by doing so appropriately.
Click to expand...

Depends. If you want to accurately copy the holes that the original file has in the same places, use cp(1). `rsync -S` ignores sparseness in the source file and just makes sequences of zeros holes. So you get sparse files where you had none before.
 
I have a love-hate relationship with rsync(1). I can't live without it, but it's default behaviour is to favour speed over correctness, which I despise. For instance, it will, by default, remove hard links (and replace them with copies of files). To make it behave "correctly" you have to invoke a lot of options. I generally start with rsync -SHAXax. Also, I don't believe that there is any way to preserve the exact sparseness when copying a source file. Your option with rsync is to make a target file either maximally sparse, or not sparse at all -- and that's generally OK.
 
gpw928 said:
I have a love-hate relationship with rsync(1). I can't live without it, but it's default behaviour is to favour speed over correctness, which I despise. For instance, it will, by default, remove hard links (and replace them with copies of files). To make it behave "correctly" you have to invoke a lot of options. I generally start with rsync -SHAXax. Also, I don't believe that there is any way to preserve the exact sparseness when copying a source file. Your option with rsync is to make a target file either maximally sparse, or not sparse at all -- and that's generally OK.
Click to expand...

Yes, a run with `rsync --sparse` will make the whole target tree maximally sparse, not just files that were sparse before.

That can be a problem when you have some files with large sequences of zeros that you deliberately did not make sparse.
 
You must log in or register to reply here.
Back
Top