rsync e xfr # 1, to-chk = 0/1, o que eles significam?

Question

Eu faço coisas como: -

$ copy debian-8.2.0-amd64-DVD-1.iso /media/shirish/4719-38E5/

Copiar aqui é um alias para: -

$ alias copy
alias copy='rsync --progress -ravz'

Quando ele faz o comando, leva muito tempo para ser concluído e faz: -

$ copy debian-8.2.0-amd64-DVD-1.iso /media/shirish/4719-38E5/
sending incremental file list
debian-8.2.0-amd64-DVD-1.iso
  3,607,855,104 100%    9.11MB/s    0:06:17 (xfr#1, to-chk=0/1)

sent 3,466,268,276 bytes  received 35 bytes  3,481,937.03 bytes/sec
total size is 3,607,855,104  speedup is 1.04

Agora tenho duas perguntas: -

a. -z no rsync não está documentado, alguém sabe o que ele faz? É muito possível que a bandeira estivesse lá antes e não esteja mais lá.

Outra coisa, alguém sabe o que o xfr#1, to-chk=0/1 realmente faz?

Eu costumo executar sync depois que o comando é concluído, alguém sabe se está tudo bem em usá-lo ou não, já que a cópia demora muito.

Além disso, as pessoas podem ter maneiras mais agradáveis e melhores para que eu possa usar um alias para realizar o mesmo. Para mim, ter progresso é importante. Alguns meses atrás, eu encontrei um cp avançado que também tem uma barra de progresso para mostrar o progresso de um arquivo sendo copiado.

Esperançoso de uma resolução rápida do acima.

    

Answer 1

Foi resolvido -

-z, --compress              compress file data during the transfer
    --compress-level=NUM    explicitly set compression level

this part seems to be the interesting one.

    --progress

This option tells rsync to print information showing the progress of the transfer. This gives a bored user something to watch. With a modern rsync this is the same as specifying

    --info=flist2,name,progress

but any user-supplied settings for those info flags takes precedence (e.g. "--info=flist0 --progress").

While rsync is transferring a regular file, it updates a progress line that looks like this:

782448  63%  110.64kB/s    0:00:04

In this example, the receiver has reconstructed 782448 bytes or 63% of the sender’s file, which is being reconstructed at a rate of 110.64 kilobytes per second, and the transfer will finish in 4 seconds if the current rate is maintained until the end.

These statistics can be misleading if rsync’s delta-transfer algorithm is in use. For example, if the sender’s file consists of the basis file followed by additional data, the reported rate will probably drop dramatically when the receiver gets to the literal data, and the transfer will probably take much longer to finish than the receiver estimated as it was finishing the matched part of the file.

When the file transfer finishes, rsync replaces the progress line with a summary line that looks like this:

1,238,099 100%  146.38kB/s    0:00:08  (xfr#5, to-chk=169/396)

In this example, the file was 1,238,099 bytes long in total, the average rate of transfer for the whole file was 146.38 kilobytes per second over the 8 seconds that it took to complete, it was the 5th transfer of a regular file during the current rsync session, and there are 169 more files for the receiver to check (to see if they are up-to-date or not) remaining out of the 396 total files in the file-list.

In an incremental recursion scan, rsync won’t know the total number of files in the file-list until it reaches the ends of the scan, but since it starts to transfer files during the scan, it will display a line with the text "ir-chk" (for incremental recursion check) instead of "to-chk" until the point that it knows the full size of the list, at which point it will switch to using "to-chk". Thus, seeing "ir-chk" lets you know that the total count of files in the file list is still going to increase (and each time it does, the count of files left to check will increase by the number of the files added to the list).