DSM-G600, DNS-3xx and NSA-220 Hack Forum

It has been asked and answered. Search is your friend.

@fun

I figured as much, but there doesn't appear to be a verbose mode in busybox's implementation of it, which is kind of weird.

Last edited by skootles (2011-06-20 15:25:32)

I would rather know what's going on and sacrifice a little time.

I actually remembered rsync which has the --progress argument which lets me see the status of transfers and see if any failed to copy.

If you want to have everything run in the background (allowing your laptop to leave the network) you can do the following:

1) ssh/telnet to the dns 323
2) run:
        at now

at runs commands in the background similar to a cron job.

3) a prompt will appear and you will type the commands you want I suggest:
echo start cp command &> out.out
cp -af /SRC /DEST  &> out.out
echo cp command finished starting rsync command &> out.out
rsync /SRC/ /DEST/ -a -vi &> out.out
Ctrl-D

The -af option will preserve times and permissions in the cp
The rsync -a -vi will clean up anything that was lost broken or screwed up in the cp
The -vi option will tell you what cp screwed up
All this output will be left in out.out so you can check out things by simply cat out.out
Ctrl-D inserts an end of file character to the terminal and instructs at that you have finished entering commands

4) Optionally you can confirm that at is running by typing:
atq

Further more a simple cat out.out will tell you where it is in the process.
Then as always 'top' and 'ps' will tell you what is going on

5) once you are satisfied everything is running ok 'exit' from ssh/telnet and go on with your day

....
....
...

6) Once you think everything should be done simply ssh/telnet in and inspect out.out to see what happened....

Take Care
Mike

As already pointed out in this thread, Rsync is slow. "cp" is significantly faster.  They perform similar, but different functions.

Last edited by FunFiler (2011-07-08 00:34:31)

You can specify options to cp to preserve the information that you want.

Try an internet search on "man cp".  Note the -a or --preserve= option.

rsync is designed to SYNCronize files between Remote machines.  (Note the capitalized R and SYNC).  When run locally, rsync will actually start a process for the source files, and a process for the destination files and copy the file data over IPC between the two processes.  There is probably verification and maybe compression/decompression going on and that won't help on a weak ARM processor.  All this is pure overhead compared to cp, so if you want to do it that way, expect things to be much slower.

rsync excels at what it is designed to do.  As mentioned here, you might consider using cp for the initial copy and then rsync (even locally) to keep up with relatively small changes.

Not my idea - it was already discussed in this thread.  I've never done it that way, partly because I was willing to let rsync make the initial copy.   There were not that many files in the source to begin with.  My machine is a server and it doesn't bother me too much if it is spending some time copying files.

If you are not sure how cp works, even after reading a man page, it is easy enough to test:

root@Toaster:~# cd /tmp
root@Toaster:/tmp# touch a
root@Toaster:/tmp# ln a b
root@Toaster:/tmp# ls -l a b
-rw-r--r-- 2 root root 0 Jul  8 09:12 a   <<<---- The 2's imply that the files are linked
-rw-r--r-- 2 root root 0 Jul  8 09:12 b
root@Toaster:/tmp# mkdir aa
root@Toaster:/tmp# cp -a a b aa
root@Toaster:/tmp# ls -l aa
total 0
-rw-r--r-- 2 root root 0 Jul  8 09:12 a  <<<---- The links are preserved with -a
-rw-r--r-- 2 root root 0 Jul  8 09:12 b
root@Toaster:/tmp# mkdir bb
root@Toaster:/tmp# cp a b bb
root@Toaster:/tmp# ls -l bb
total 0
-rw-r--r-- 1 root root 0 Jul  8 09:13 a <<<---- The links are not preserved
-rw-r--r-- 1 root root 0 Jul  8 09:13 b

It may not be a bad idea to copy a subset of your file tree over to the backup and then look at the results to make sure you have the cp parms the way you want.

Just for completeness, some people replicate file trees using a tar pipe.  Tar is pretty good at preserving file attributes.

See:
http://www.commandlinefu.com/commands/v … e-to-cp-ra

For measuring cp's throughput, I would just make a large file that would take a minute or so to copy and then time it:

root@Toaster:~# cd /mnt/HD_a2
root@Toaster:/mnt/HD_a2# dd if=/dev/zero of=test count=1048576 bs=1024
1048576+0 records in
1048576+0 records out
1073741824 bytes (1.1 GB) copied, 43.7581 s, 24.5 MB/s
root@Toaster:/mnt/HD_a2# time cp test /mnt/HD_b2

real    0m48.907s
user    0m0.140s
sys     0m33.790s


or about 22 MB/s

The throughput will probably be a bit slower if you have a lot of small files.  So, it will depend a lot on the type of data you have stored.  But you should be able to approach the rate for a single large file is you have a large set of media files like music and video.

I have other problem with copy. The file name characters are corrupted. maybe it is a codepage problem. But how to solve this?