Why does the rsync not allow block-size>128K

Your .profile is only read when you log in interactively. When rsync connects to another machine to execute a command, /etc/profile and ~/.profile are not read.

If your login shell is bash, then ~/.bashrc may be read (this is a quirk of bash — ~/.bashrc is read by non-login interactive shells, and in some circumstances by login non-interactive shells). This doesn't apply to all versions of bash though.

The easiest way to make rsync work is probably to pass the --rsync-path option, e.g.

rsync --rsync-path=/home/elbarna/bin/rsync -avP /home/user/.profile hpux3:/home/user/.profile

If you log in over SSH with key-based authentication, you can set the PATH environment variable via your ~/.ssh/authorized_keys. See sh startup files over ssh for explanations of how to arrange to load .profile when logging in over SSH with a key.

To answer the main question in short, rsync seems to write double the number of bytes, because it spawns two processes/threads to do the copy, and there's one stream data between the processes, and another from the receiving process to the target file.

We can tell this by looking at the strace output in more detail, the process IDs in the beginning of the file, and also the file descriptor numbers in the write calls can be used to tell different write "streams" from each other.

Presumably, this is so that a local transfer can work just like a remote transfer, only the source and destination are on the same system.

Using something like strace -e trace=process,socketpair,open,read,write would show some threads spawned off, the socket pair being created between them, and different threads opening the input and output files.

A test run similar to yours:

$ rm test2
$ strace -f -e trace=process,socketpair,open,close,dup,dup2,read,write -o rsync.log rsync -avcz --progress test1 test2
$ ls -l test1 test2
-rw-r--r-- 1 itvirta itvirta 81920004 Jun 21 20:20 test1
-rw-r--r-- 1 itvirta itvirta 81920004 Jun 21 20:20 test2

Let's take a count of bytes written for each thread separately:

$ for x in 15007 15008 15009  ; do echo -en "$x: " ; grep -E "$x (<... )?write"  rsync.log | awk 'BEGIN {FS=" = "} {sum += $2} END {print sum}'  ; done 
15007: 81967265
15008: 49
15009: 81920056

Which matches pretty much with the theory above. I didn't check what the other 40kB written by the first thread is, but I'll assume it prints the progress output, and whatever metadata about the synced file rsync needs to transfer to the other end.

I didn't check, but I'll suggest that even with delta compression enabled, perhaps the "remote" end of rsync still writes out (most of) the file in full, resulting in approximately the same amount of writes as with cp. The transfer between the rsync threads is smaller, but the final output is still the same.